Managing a shared resource without locks
I've got 3 or more sensor cogs (CNe,HNe,SNe) that want to
send commands and data to a common worker cog (HNf)
whose job it is to manage a shared resource
like an SDcard or eeProm...
The commands are simple get/put to the resource
readL(DEVaddr, HUBloc);
writeL(DEVaddr, HUBloc);
I may add more commands in the future. Each sender will
wait for a previous command to complete or an error before sending again.
To communicate, I will need to pass 2 longs and a command (minimum).
I don't care if the command is a long or a byte. There could be many ways to error
but, more or less, only one way to signal success [noparse][[/noparse]typically by zeroing the command byte].
CNe (See no evil), HNe (Hear no evil) and SNe (Speak no evil)
each separately 'own' some hub memory as does HNf.
Can communications with HNf
be done without involving a Lock?
It should work with more than three callers too...
I do not want to have to change the code to HNf every time I add a sensor.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-bobR
send commands and data to a common worker cog (HNf)
whose job it is to manage a shared resource
like an SDcard or eeProm...
The commands are simple get/put to the resource
readL(DEVaddr, HUBloc);
writeL(DEVaddr, HUBloc);
I may add more commands in the future. Each sender will
wait for a previous command to complete or an error before sending again.
To communicate, I will need to pass 2 longs and a command (minimum).
I don't care if the command is a long or a byte. There could be many ways to error
but, more or less, only one way to signal success [noparse][[/noparse]typically by zeroing the command byte].
CNe (See no evil), HNe (Hear no evil) and SNe (Speak no evil)
each separately 'own' some hub memory as does HNf.
Can communications with HNf
be done without involving a Lock?
It should work with more than three callers too...
I do not want to have to change the code to HNf every time I add a sensor.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-bobR
Comments
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
I am asking because I do see counter examples of this
in which the recipient owns the memory locations
and I guess those are limited to only single-sender situations.
For multiple senders -
When N cogs are sending (multi-long) messages to a single receiver,
each must own their own buffer for the message
and write the command or 'do-this' portion last
so that arguments are not fetched before they are ready.
Can this be made to work when the recipient publishes
only a single 'mailbox' in which to receive pointers to messages?
Is there an example of this in the library?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-bobR
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
to code up the [noparse][[/noparse]CHS]Ne side to do this, it would look like:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-bobR
It isn't exactly the same problem you're working on, but it might give you some ideas. The basic concept for lock-free concurrency is summed up in this quote: "The producer and consumer always work in separate parts of the underlying list, so that their work won't conflict."
Of course, the article assumes only 1 producer and 1 consumer, and in fact the article is about how *hard* or *dangerous* lock free code is - but, the fascinating part IMO is that it is at least possible to write code that is both lock-free and works correctly, at least for some cases. I just thought that was very interesting because I've read a lot about multithreading elsewhere, and never did anyone mention the kind of lock-free techniques talked about in the article.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Just a few PropSTICK Kit bare PCBs left!
I want to stay focused on M:1, 1:N and M:N solutions if possible. I have
examples of 1:1 messaging solutions provided by Andre in the hx512 code.
My hope is to come up with a verified standard in both C and prop asm
that many here can use/reuse. I will reuse them too for some of the
even bigger things I have planned to release to this forum.
I will start with simple stuff like datalogging from multiple sensors
because that more or less parallels the problem set of an operating
system which has to service requests from many concurrent applications.
I had constrained the HNf module to not have to be extended every time
a new sensor was added because [noparse][[/noparse]in an operating system] you probably
don't want to have the device drivers to have knowledge
of every application you plan to run.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-bobR