On Thu, Aug 02, 2001 at 12:09:05PM -0400, Victor J. Orlikowski wrote:
> Aaron Bannert writes:
> > On Tue, Jul 31, 2001 at 06:31:23PM -0400, Victor J. Orlikowski wrote:
> > > Rather, let's be more clear.
> > >
> <snip>
> >
> My fault. That code is more than slightly wrong, now that I look
> at it better. Let's examine the following pseudocode, which closely
> follows some of my undergraduate OS work at the university.
> I will not be doing any checking for null values, etc.
>
> struct Condition {
> mutex *lock; /* mutex associated with condition */
> int thread_id; /* Current holder of the lock */
> mutex condlock;
> };
>
> void Wait(struct Condition *c) {
> acquire(c->condlock);
> if (c->thread_id != thread_id_of(current_thread)) {
> release(c->condlock);
> exit(-1); /* Only the holder of the lock may call wait */
> }
> l->thread_id = -1; /* or whatever invalid thread value */
> release(c->condlock);
> release(*(c->lock));
> wait_on_signal_or_broadcast(); /* hint, use a semaphore */
> acquire(*(c->lock));
> acquire(c->condlock);
> c->thread_id = thread_id_of(current_thread);
> release(c->condlock);
> }
>
> void Signal(struct Condition *c) {
> if (c->thread_id != thread_id_of(current_thread))
> exit(-1); /* Only the holder of the lock may call signal */
> wake_one_sleeper();
> }
>
> void Broadcast(struct Condition *c) {
> if (c->thread_id != thread_id_of(current_thread))
> exit(-1); /* Only the holder of the lock may call broadcast */
> wake_all_sleepers();
> }
>
> > Not really, but maybe I'm just being dense. Assuming "mutex1" is the
> > mutex associated with the condition (and therefore has the same scope),
> > what is the scope of "mutex2" and "held"?
> >
> The scope of mutex2 is not associated with the condition; it is
> intended to provided the needed mutual exclusion for mutex1 and the
> state variable held. However, you can ignore this, since that code was
> slightly wrong.
>
> > And more importantly, if you're using sleep(), then aren't you just doing
> > a primitive poll/wait loop, and therefore defeating the whole purpose
> > of event-based scheduling using CVs?
> Sleep() was not intended to be sleep; I was writing pseudocode.
> Sleep() was a place holder for whatever function you are calling
> that is used to block the current thread until is is awakened via a
> signal() or broadcast() operation. Hopefully I'm more clear in the
> above example.
Fair enough. The above is much more clear, but there is now another
problem...
>
> Does the new code fit better with what you expect?
In your above example, how can more than one thread be wait()ing on
a condition, if only the thread that has the "c->lock" may call
wait()?
Also, Signal() and Broadcast() may not be MT-safe, as they perform
operations on c->thread_id that are non-exclusive and may be non-atomic
on some platforms.
-aaron
