Re: [Avf-fuse-dev] Multithreaded communication.

[<Mik...@et...>]

> In my project, all the processes are talking to one physical device (the
> 1-wire bus over a serial or USB connection), and then to multiple
> devices on that bus. It's easy to lock the bus for each message, but an
> entire transaction may take several messages, with pauses for processing
> by the peripheral device. Thus I need both bus locking, and periperal
> device locking.

Yes.  The important thing is to always do locking of these in the same
order, otherwise a deadlock could occur.  But this case is pretty
obvious: the device lock should be the outer and the bus lock the
inner one.

> Picture:
> 
> thread\                           /device
> thread-}--serialport--1wire bus--{-device
> thread/                           \device
> 
> Since the threads know the device they are talking to, and have
> mutex/non-race communications, I'd like a thread to scan it's brothers,
> find any one that is accessing the same device, and either block till
> it's done, or transfer it's task.

It must block and not transfer the task, since the function can only
return if the the task is completed.  

> Right now, the threads really don't know about each other. I'd have to
> make a global array, and have them coordinate through that. Much less
> elegant.

If it's hard to keep track of the devices that are currently used,
then you can use hashed locking: There is a fix sized table containing
the locks, and you use a hash function to generate the table index
from the device name.  This may not be optimal, since two devices may
share the same lock, but if the table is large enough, its not really
a problem.

Miklos
-- 
At the end of this message, my employer might have automatically
inserted a stupid disclaimer. This nonsense is out of my control and
should simply be ignored.

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.