> Simply reading from a shared variable is not atomic. All accesses to a
> shared variable must be synchronized (or "serialized", if you prefer)
> with some form of mutual exclusion. (An example of this is on
> Solaris/Sparc, where a context switch can occur half-way through an update to
> a longword (or is it a word, I'm not sure).
>
Since this is a problem, we can simply protect the test with the
condlock. Not a big change.
> > int Acquire_Condition_Lock(struct Condition *c) {
> > if (c->thread_id != -1)
> > return -1; /* Somebody's got the lock */
> > acquire(c->condlock);
> > acquire(*(c->lock));
> > c->thread_id = thread_id_of(current_thread);
> > release(c->condlock);
> > return 0;
> > }
>
> Unfortunately this won't work. If two threads are trying to signal
> they will both have to run Acquire_Condition_Lock(). The second one
> will fail. What then, spin? No.
All right. This is a valid problem.
How about:
int Acquire_Condition_Lock(struct Condition *c) {
acquire(c->condlock);
acquire(*(c->lock));
c->thread_id = thread_id_of(current_thread);
release(c->condlock);
return 0;
}
Hence, we simply block trying to acquire the condlock.
Once we have the condlock, all is well, no?
> Moving ahead, IIRC we are confident we can safely implement condition
> variables on Win32 and Unix. What do we have for beos and os2? Are there
> other platforms that will be a problem?
>
>
> (For the curious, there is an excellent paper by Douglas C. Schmidt and Irfan
> Pyarali at http://www.cs.wustl.edu/~schmidt/win32-cv-1.html called
> _Strategies for Implementing POSIX Condition Variables on Win32_. The
> paper includes multiple strategies for implementing POSIX CVs.)
>
I'll be sure to look at these.
Victor
--
Victor J. Orlikowski | The Wall is Down, But the Threat Remains!
==================================================================
[EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED]
