in reply to Re^4: need a thread to wait until a buffer is full.
in thread need a thread to wait until a buffer is full.

Why don't you design to avoid the locking altogether? Just have 2 buffers, one in each thread. Have the first thread signal the second to start filling it's buffer, and when it's done, set a shared variable to "filled". Have your first thread watch the shared variable, and when it says "filled", copy the buffer and reset.

I'm sure there probably is a way to avoid the copying, by sharing the buffer too, but unless there are performance issues with the extra in-memory copy, it's safer and easier to keep things separate.


I'm not really a human, but I play one on earth. Cogito ergo sum a bum
  • Comment on Re^5: need a thread to wait until a buffer is full.

Replies are listed 'Best First'.
Re^6: need a thread to wait until a buffer is full.
by BrowserUk (Patriarch) on Jul 25, 2007 at 12:45 UTC
      I thought signals and threads were an iffy combination? Meaning that the main thread tends to intercept all signals? So what if you wanted 2 or 3 buffers? A shared variable can be buffer specific, whereas a signal may be non-specific. (I may have mistakenly used the word "signal" in my node above, in a generic manner, where I really meant "set a shared variable which would signal......."

      I'm not really a human, but I play one on earth. Cogito ergo sum a bum

        They aren't signals in that sense of the word. In the sense of cond_signal().

        Basically, the thread in waiting on cond_wait() will not be allocated any timeslices by the scheduler until the other thread calls cond_signal() (or broadcast). So, no polling a second shared var to see if the first is ready yet.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.