one producer thread, one consumer thread: mutex needed?

S

smith4894

Hello,

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? As I mentioned already, I have only
one reader and one writer, and the reader checks if it has enough bytes
to cast into a struct.

-Thanks.
 
W

Walter Roberson

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.programmer 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.
 
K

Keith Thompson

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.programmer. You might also try comp.programming.threads.
 
U

unoriginal_username

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

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

Shared<Counted<Queue<YourStruct> > > 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-
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top