pthreads-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pthreads-hackers] pthreads and cancellation


From: Marcus Brinkmann
Subject: Re: [Pthreads-hackers] pthreads and cancellation
Date: Sat, 26 Jan 2002 17:08:09 +0100
User-agent: Mutt/1.3.25i

On Fri, Jan 25, 2002 at 10:04:17PM +0100, Marcus Brinkmann wrote:
> I think I found a design flaw in the current pthreads implementation
> concerning conditions and cancellation.

I think I found a solution.  After thinking through various concepts that
involve more locking (with the problem that queue code would lock first A
and then B, while cancellation code would try to first lock B and then A),
or other, eventually equivalent ideas, I have come to the conclusion that
with the code as it is (eg, implementing most functionality with other
pthreads primitives), the following setup seems to be most appropriate:

A condition becomes not a struct, but a pointer to a struct.  This structure is
malloc'ed by the initialization code, or for static initializers, it is
delayed until the condition is used the first time (this is how ngpt, bsd
threads and others work, too).  The condition gets a reference count, and a
flag if it is destroyed by the user.  At initialization, every condition
gets one reference.

The condition_wait code (and timedwait) acquires a reference, which it
releases after it has used the condition (this can be in the cancellation
handler, too).  You only need to acquire a reference if you want to make
sure the condition object remains live after you release its lock.

The condition_destroy code sets the destruction flag and releases a
reference (and clears the user's condition object, eg the pointer).

After the last reference has been released, the condition object is free'd.

The effect of this design is that the internal condition object, most
importantly its queues and destruction status, is decoupled from the user
controlled condition object, which might get reused while the internal
object (or at least its state) must persist.  The reference counting is
necessary for multiple waiters.  It will be very cheap to implement.  The
main change is that condtion calls can fail because we have to use malloc.
One advantage is that I believe we can achieve better error checking for the
user.  And it is possible to achieve binary compatibility even if the
condition structure is changed (although this will probably not be
implemented, at least initially).

I will implement this is if nobody has a better idea.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org address@hidden
Marcus Brinkmann              GNU    http://www.gnu.org    address@hidden
address@hidden
http://www.marcus-brinkmann.de



reply via email to

[Prev in Thread] Current Thread [Next in Thread]