This is the mail archive of the
pthreads-win32@sources.redhat.com
mailing list for the pthreas-win32 project.
Re: starvation in pthread_once?
- From: Alexander Terekhov <TEREKHOV at de dot ibm dot com>
- To: Ross Johnson <rpj at callisto dot canberra dot edu dot au>
- Cc: Pthreads-Win32 list <pthreads-win32 at sources dot redhat dot com>
- Date: Tue, 8 Mar 2005 10:48:56 +0100
- Subject: Re: starvation in pthread_once?
[... pthread_once() and cancelation ...]
> Should one or more waiting threads get woken up and made to
> re-compete to run the init routine?
Yes. As for the rest, what you need here is DCSI-TLS or DCSI-MBR
(acquire/release memory barriers are needed on both Itanic and
XBOX NEXT... and, apart from hardware memory model, compiler
shall respect acquire/release semantics on IA-32 as well). For
serialization simply use a named mutex associated with address
of control variable and process id (to minimize contention).
DCSI-TLS: (__declspec(thread) for control variable; DLL issues
aside for a moment)
if (!once_control) {
named_mutex::guard guard(&once_control);
if (!once_control) {
<init>
once_control = true;
}
}
DCSI-MBR: (atomic<> for control variable)
if (!once_control.load(msync::acq)) {
named_mutex::guard guard(&once_control);
if (!once_control.load(msync::none)) {
<init>
once_control.store(true, msync::rel);
}
}
regards,
alexander.