Best way to share data between threads

Giorgos Keramidas keramida at
Tue Feb 22 12:43:53 GMT 2005

On 2005-02-22 12:19, Jonathon McKitrick <jcm at> wrote:
>On Tue, Feb 22, 2005 at 08:38:11AM +0200, Giorgos Keramidas wrote:
>:On 2005-02-22 05:50, Jonathon McKitrick <jcm at> wrote:
>:> Hi all,
>:> I'm porting some libraries from Win32 to BSD/Linux.  In the
>:> original code, I receive a Windows event with an attached COM
>:> object.
>:> Under *nix, what is the best way to copy this?  A message,
>:> followed by accessing shared memory between threads?
>: Does the message really have to be shared across many threads?  I'm
>: only asking because thread-specific message queues are not that
>: hard to build with pthreads.  You will only need a per-thread queue
>: to hold messages and a master thread that 'dispatches' messages to
>: the proper thread/queue.
> Well, there will be a data acquisition thread, that when finished,
> will need to signal the main processing thread that a new data
> object has arrived.

There are a couple of ways to do the notification:

	1) Explicit notification using a condition variable.

	2) No notification at all, but restructuring of the thread
	   code to use message queues.

The first can be accomplished by associating a pthread_cond_t with the
data storage area and explicit signalling of the processing thread.
Every time the processing thread has nothing to do (i.e. no data being
processed at the time), it blocks on the condition variable and waits
until the data acquisition thread awakes it.

The second way to solve this is to use minimal synchronization (i.e. a
mutex to protect a common message queue) and a queue of currently
pending messages.  The data acquisition thread gets a copy of the data
and pushes it on the queue, leaving all further work to the processing
thread.  The processing threads awakes periodically, "polling" for new
messages in the queue.  When one is found, it is immediately processed.
When no message is found, the processing thread sleeps for a small
amount of time.

More information about the freebsd-questions mailing list