467,081 Members | 1,251 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,081 developers. It's quick & easy.

one producer thread, one consumer thread: mutex needed?

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.

Nov 15 '05 #1
  • viewed: 3253
Share:
3 Replies
In article <11*********************@g14g2000cwa.googlegroups. com>,
<sm*******@excite.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.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.
--
"Never install telephone wiring during a lightning storm." -- Linksys
Nov 15 '05 #2
sm*******@excite.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.programmer. You might also try comp.programming.threads.

--
Keith Thompson (The_Other_Keith) 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.
Nov 15 '05 #3
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-

Nov 15 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Debaser | last post: by
7 posts views Thread by Evan Simpson | last post: by
3 posts views Thread by MrNobody | last post: by
2 posts views Thread by Rene Ruppert | last post: by
22 posts views Thread by Morpheus | last post: by
4 posts views Thread by mps | last post: by
10 posts views Thread by George Sakkis | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.