Is Message passing good approach for multi-threaded applications?
Behzad
I am currently developing an embedded protocol converter.In this
application there are 16 serial ports and 2 Ethernet ports.There are
16 threads for each serial port and also there is a network server
which accepts connections from LAN. so there is a thread per each
connection.There are also some threads for other tasks like
application management, time synchronization etc. As a solution to the
problem of communication between these threads i choose message
passing.There are 2 queues.One for requests and one for responses. LAN
threads put messages into request queue and other threads put replies
into response queue. Because our system has a CPU with 500MHz speed
(ARM9) i was concern if this approach can satisfy our
requirement.Each request and subsequent response should take only 200
ms. Does this architecture ( message passing as a communication bus )
good or there are some other approaches? Any guide,URL, book,
experience would appreciated.
Thanks in advance
Behzad
Szabolcs Ferenczi
No, I am afraid not. Multi-threading is there for shared memory
communication. If you use message passing, that means you are working
with distributed processes. So, you do not need shared memory
communication (threads) any more.
Best Regards,
Szabolcs
Chris M. Thomasson
[top-post correction]
> Behzad wrote:
>> hi all,
>>
>> I am currently developing an embedded protocol converter.In this
>> application there are 16 serial ports and 2 Ethernet ports.There are
>> 16 threads for each serial port and also there is a network server
>> which accepts connections from LAN. so there is a thread per each
>> connection.There are also some threads for other tasks like
>> application management, time synchronization etc. As a solution to the
>> problem of communication between these threads i choose message
>> passing.There are 2 queues.One for requests and one for responses. LAN
>> threads put messages into request queue and other threads put replies
>> into response queue. Because our system has a CPU with 500MHz speed
>> (ARM9) i was concern if this approach can satisfy our
>> requirement.Each request and subsequent response should take only 200
>> ms. Does this architecture ( message passing as a communication bus )
>> good or there are some other approaches? Any guide,URL, book,
>> experience would appreciated.
>>
>> Thanks in advance
"Szabolcs Ferenczi" <szabolcs...@gmail.com> wrote in message
news:3db751a7-460a-4a5f...@f63g2000hsf.googlegroups.com...
> "Is Message passing good approach for multi-threaded applications?"
>
> No, I am afraid not. Multi-threading is there for shared memory
> communication. If you use message passing, that means you are working
> with distributed processes. So, you do not need shared memory
> communication (threads) any more.
You can most certainly use message-passing in multi-threaded applications.
Also, its a great abstraction for threading indeed. It can actually be
implemented with virtually zero-overheads. It has excellent scalability
characteristics. IMHO, its a great method to address multi-threaded
programming.
Szabolcs Ferenczi
applications but multi-threading has been invented for shared memory
communication. Message passing, on the other hand, matching with
distributed memory communication.
> Also, its a great abstraction for threading indeed. It can actually be
> implemented with virtually zero-overheads. It has excellent scalability
> characteristics. IMHO, its a great method to address multi-threaded
> programming.
Yes, message passing is scalable much more than shared memory
communication only multi-threading is not about message passing
techniques.
Best Regards,
Szabolcs
Chris M. Thomasson
Multi-threading and message-passing work very well together. Do you
disagree?
Chris M. Thomasson
One little nit-pick... message-passing can be implemented on top on
shared-memory, therefore, within that scenario, msg-passing is shared-memory
communication and vise-versa.
Anthony Williams
Message passing is certainly a reasonable option for communicating
between threads. However, I would still question why you need this
many threads. Can you use select() or something similar to check for
data from the serial ports in a single thread? Depending on the
scenario, it might be better to have a single master thread taking
messages on all connections and serial ports, and passing these
messages out to a set of worker threads (tuned to the number of
CPUs/cores in the system) rather than having one thread per LAN
connection and one per serial port. Certainly
one-thread-per-LAN-connection is not scalable to large numbers of
connections/threads.
Anthony
--
Anthony Williams | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
David Schwartz
> Message passing is certainly a reasonable option for communicating
> between threads. However, I would still question why you need this
> many threads. Can you use select() or something similar to check for
> data from the serial ports in a single thread? Depending on the
> scenario, it might be better to have a single master thread taking
> messages on all connections and serial ports, and passing these
> messages out to a set of worker threads (tuned to the number of
> CPUs/cores in the system) rather than having one thread per LAN
> connection and one per serial port. Certainly
> one-thread-per-LAN-connection is not scalable to large numbers of
> connections/threads.
An approach that sometimes works well is a pool of symmetric threads.
The thread works like this:
Basic loop:
1) Acquire the pool mutex.
2) If no job on the queue, skip to "No Job".
3) Remove the head job from the queue.
4) Release the pool mutex.
5) Do the job.
6) Go to step 1.
No Job:
1) Increment the count of idle threads.
2) If we are the only idle thread skip to "Nothing to do".
3) Release the pool mutex.
5) Call 'select' or 'poll' to look for new work to do.
6) Acquire the pool mutex.
7) Did we find any new jobs? If so, queue them and signal the pool
condvar.
8) Decrement the number of idle threads.
9) Jump to step 2 of "Basic loop".
Nothing to do:
1) Block on the pool condvar, releasing the mutex.
2) Go to step 2 of "Basic loop".
DS