Consensus on Concurrency?


#1

Hello Everyone,

I’ve looked through the Dexter Industries Forums and spent some time on Stack Overflow, but I’m not sure I’ve found “best practices” to have the Raspberry Pi based robots complete different actions relatively simultaneously.

Threading seems to be the most obvious approach, but there are other options such as queueing or asyncio.

For my intended application, I’m using BrickPi and want to:

  • Monitor sensors
  • Run Motors
  • work with sensor values - probably lots of math :slight_smile:
  • write files
  • connect with other wi-fi enabled devices

Sorry if I’ve missed the question in other parts of the forum - pointers welcome.

Thanks!


#2

hi,
of course there will not be 1 answer which solves all existing problems. And above all, the question is not, which millions of things you want to do, but if there are threads which are time-sensitive and will get stuck when being processed in a queue or not.
And that eventually is already the ultimate answer to qeueing, multithreading, and anything - in other words:
as much queueing as possible and as little multithreading as possible, and all depending on the features of your programming language,

As to me, I am using MT already since about 15 years. Currently I use the BrickPi3 with C++ and (when required) POSIX pthread by different thread priorities plus mutexes, and also Arduinos with Patel’s and Maglie’s Scheduler libs, and it (mostly) works like a charme.
(Additionally, sometimes also pinchange Interrupts might be a possible option , but I don’t use them generally.)


#3

Take a look at this forum thread.


#4

@rolly – Thanks Rolly - I will take a look through the code you posted. The discussion also deserves some study. Thanks for the pointers!


#5

@HaWe - Thanks. I appreciate the feedback. I figured the answer would be the always true, and almost always useless “it depends,” – but your comments about queueing vs multithreading are very helpful. Thanks for sharing your experience.


#6

Hi @craig.shelden,

Personally, I think I would go with some sort of topic/direct-based queuing to do the following:

  1. Send data from the sensors down to a processing service - which does the number crunching.

  2. Send processed data to a manager service that aggregates the data coming from the sensor and from the user into a final command which then gets relayed to a motor service.


Or I may go with separating the number crunching operations and the processing of data and actuation into 2 separate processes. In this case, the process which deals with processing the data and actuating the robot would implemented some sort of MT or asyncio.


All in all, I would push for segregating different components of the project into as many services as possible. The idea is to reduce them to the level of irreducibility.

Thank you!


#7

Thanks Robert.

I generally agree with idea of separating the program flow paths, but I’ve got to explore it more to ensure against some of the issues like “race conditions” that I’ve read about, but never yet experienced. Yes, this text-based parallel programming is somewhat new to me.

I don’t want to be spoon-fed, but pointers to solid examples always welcome.

Thanks! I’ll keep working the problems.

All my best,

craig


#8

hi,
you don’t have to worry about race conditions as long as your functions won’t write to any shared variable from 2 or more different threads simultaneously.
I case that might happen, you either put your write-functions into 1 single thread and queue them up, or, alternatively, wrap mutexes around them to prevent your variables from simultaneous write actions.

Which is your programming language?