apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Victor J. Orlikowski" <v.j.orlikow...@gte.net>
Subject Re: Conditionals...
Date Thu, 02 Aug 2001 16:09:05 GMT
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.

Does the new code fit better with what you expect?

Victor
-- 
Victor J. Orlikowski   | The Wall is Down, But the Threat Remains!
==================================================================
v.j.orlikowski@gte.net | orlikowski@apache.org | vjo@us.ibm.com

Mime
View raw message