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

The buffer contains raw binary data that can be anything, it is directly read from the hd, the other thread will read a block from the hd and put it into the buffer. I know that lock goes away after the scope {}. my problem is how do I ensure the thread that fills the buffer locks it before the thread that created it checks it. I do not want my thread that uses the buffer to lock it so that it can check if it is filled, then have the thing that fills it sit there and wait since the thread that uses it has the lock.... essentially my question is this: If I use lock in a loop, then when the loop goes to the next iteration is that going out of scope and releasing the lock, or is it holding the lock since it is one loop?

--------------------------------------

I would rather take 30 minutes to re-invent the wheel then take 30 days to learn how to use someone else's. Before pestering me about my re-invention prepare to defend yourself with a way of learning how to use the wheel in less time than it takes for me to make one, one that I might add is specialized to my specific task!

  • Comment on Re^4: need a thread to wait until a buffer is full.

Replies are listed 'Best First'.
Re^5: need a thread to wait until a buffer is full.
by zentara (Cardinal) on Jul 25, 2007 at 12:17 UTC
    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
[reply]
[reply]
        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
[reply]

In Section Seekers of Perl Wisdom