one producer thread, one consumer thread: mutex needed?

In article <11************ *********@g14g2 000cwa.googlegr oups.com>,
<sm*******@exci te.com> wrote:

I have an application that essentially consists of two threads doing
their things. One thread is a producer, and pushes bytes (of a struct)
into a pipe, and another is a consumer that simply checks the pipe at
regular intervals reads out the bytes. If the consumer extracts bytes
and sees that it's not enough to recast to the struct, it caches it and
waits for more bytes in the pipe. My question is: Do I still need to maintain a mutex that is locked
whenever a thread writes or reads?

One of the newsgroups you posted to is comp.lang.c, which talks
about what is possible in standard C -- talks about that which
is portable and well-defined behaviour.

In standard C, neither "pipe" nor "mutex" have any meaning.

The technical meaning of "mutex" is relatively narrow... but
it happens that there is no portable way to implement a mutex
in portable C.

There are a number of different common meanings for "pipe",
some of which are implementable in portable C and most of which are
not. In the ones which -are- implementable in portable C...
well, in a way it doesn't matter much anyhow, as portable C does not
offer any form of multiprocessing , and if you wanted to deliberately
switch your single-threaded program between producer and consumer
mode while you were in the middle of updating your "pipe" structures,
then the C language isn't going to protect you from any inconsistancies
that result.
The fact that you cross-posted to comp.unix.progr ammer likely
indicates that you had a fairly specific meaning of "pipe" in mind,
and indicates that you likely had at least minimal multiprocessing
open to you as a possibility ("fork"). But it doesn't tell us which
Unix or Unix Standard you are working against, nor which POSIX
standards that Unix complies with, and it doesn't nail down
whether you are just using fork() or if you are using popen()
or if you are using sockets, or pthreads... and it is possible you were
using "pipe" loosely... And we don't know whether the particular -kind-
of mutex you are using is sufficient to between your producer and
your consumer...
But aside from all of that, if you are using anything approximating
a recent Unix, then the answer to your question is *likely* "Yes".

When you write to a Unix pipe, the Unix I/O layer ensures that there
are no inconsistancies in the I/O presentation. For example, it will
ensure that the size of the available data is not incremented
before the data is readable, so you do not have to worry about
being told that data is there and then getting nonsense in the
buffer because it hasn't been delivered yet.

On the other hand, if your "pipe" is not a pipe() or popen() and
is instead a read/write fd or FILE* being shared between a parent
process and another process fork()'d from it, then -effectively-
you *do* need a mutex, as POSISX does not allow you to shift
a shared fd or FILE* between reading and writing without undertaking
certain precautions first. The exact set of precautions takes
at least 1 1/2 printed pages of the POSIX.1-1990 standard, and is
perhaps most easily dealt with via a mutex or at least through
advisory shared volatile variables.
--
"Never install telephone wiring during a lightning storm." -- Linksys

sm*******@excit e.com writes:

I have an application that essentially consists of two threads doing
their things. One thread is a producer, and pushes bytes (of a struct)
into a pipe, and another is a consumer that simply checks the pipe at
regular intervals reads out the bytes. If the consumer extracts bytes
and sees that it's not enough to recast to the struct, it caches it and
waits for more bytes in the pipe.

[...]

Standard C doesn't have threads. Followups redirected to
comp.unix.progr ammer. You might also try comp.programmin g.threads.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

What you need is a shared, counted queue of structures.

In C++, one might define the queue as:

Shared<Counted< Queue<YourStruc t> > > queue;

Shared<> is wrapper template that gives any struct a mutex with
acquire()/release() members.
Counted<> is wrapper template that gives any struct a semaphore with
raise()/lower() members.

// Producer does this:
queue.acquire() ; // acquire exclusivity on queue
// Now you can put one of YourStruct into the queue
queue.release() ; // release exclusivity on queue
queue.raise(); // declare that there is now at least one new YourStruct
waiting in queue

// Consumer does:
queue.lower(); // block until at least one new YourStruct waiting in
queue
queue.acquire() ; // acquire exclusivity on the queue
// Now you can get one of YourStruct out of the queue
queue.release() ; // release exclusivity on queue

You should be able to translate this code to C without much effort.

-Chaud Lapin-