Date: Wed, 29 Mar 2006 12:08:26 +0200 From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: David Xu <davidxu@freebsd.org> Cc: threads@freebsd.org, jeff@freebsd.org Subject: Re: libthr cleanup Message-ID: <86k6add0md.fsf@xps.des.no> In-Reply-To: <442A55EB.9060009@freebsd.org> (David Xu's message of "Wed, 29 Mar 2006 17:39:55 %2B0800") References: <86slp1u4qb.fsf@xps.des.no> <442A466A.9040506@freebsd.org> <861wwlehvg.fsf@xps.des.no> <442A55EB.9060009@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
David Xu <davidxu@freebsd.org> writes:
> Dag-Erling Sm=F8rgrav wrote:
> > In effect, the wait / wake operations implement a condition variable.
> > You should not use the same struct (or type) to describe the condition
> > variable as the one you use to describe a mutex.
> > Condition variables are always used in conjunction with a mutex. The
> > mutex must be passed to the wait function so it can be unlocked while
> > the waiting thread waits. It must be held by the thread calling the
> > wake method. Neither the existing interface nor the one you propose
> > do this.
> You are talking about how to use it, not how to implement it.
No, I am talking about how to implement it. If you try to implement
condition variable primitives which do not require a mutex to be held,
your condition variables will not work; they may work most of the
time, but there will be races.
> > You cannot "wait for an integer to be changed" (at least not without
> > using hardware debugging facilities), and that is not what
> > UMTX_OP_WAIT does. It is a botched condition variable. It waits for
> > another thread to perform an UMTX_OP_WAKE operation with the correct
> > arguments; the fact that an integer has changed is incidental, and the
> > test for that change could be implemented in userland: look up
> > condition variables in any good CS textbook and you will see an
> > example of this, likely in the guise of a sample message queue (or
> > mailbox) implementation.
> again, there are many ways to implement it, I think you are talking
> about how to use it, not how to implement it.
Again, I am talking about how to implement them. See above.
The counter ("integer to be changed") is necessary to avoid races when
multiple threads are sleeping on the same condition variable - but the
counter itself must be protected, which is what the mutex is for. You
can't sleep with that mutex held, because the signalling thread needs
to hold the mutex while incrementing the counter and signalling the
sleeping threads. The only way to achieve this is to pass the mutex
to the wait function, so the wait function can drop it (and later
reacquire it) in a critical section.
If you remove the mutex, you need to protect your counter with a
critical section; but then you no longer have a condition variable,
but a counting semaphore. If you remove the counter, all you have
left is some kind of multicast asynchronous signal.
> I don't trust you, I don't think your work is useful to me, you are
> rushing, and command everyone to catch up with you, but we have life,
> wife, and children, I am old, I should leave FreeBSD.
???
FYI, I have a life, a job and a wife, too; and while I don't have
children, I do have a cat with chronic renal failure which requires
constant attention; but I don't use them as excuses to brush off
criticism of my work.
DES
--=20
Dag-Erling Sm=F8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86k6add0md.fsf>