This is the mail archive of the
pthreads-win32@sources.redhat.com
mailing list for the pthreas-win32 project.
Re: RE: New pthread_once implementation
- From: vkliatchko at optonline dot net
- To: Ross Johnson <ross dot johnson at homemail dot com dot au>
- Cc: Gottlob Frege <gottlobfrege at gmail dot com>,Pthreads-Win32 list <pthreads-win32 at sources dot redhat dot com>
- Date: Thu, 02 Jun 2005 08:58:59 -0400
- Subject: Re: RE: New pthread_once implementation
> -----Original Message-----
> From: Ross Johnson [mailto:ross.johnson@homemail.com.au]
> Sent: Thursday, June 02, 2005 2:20 AM
> To: Vladimir Kliatchko
> Subject: RE: New pthread_once implementation
>
> On Thu, 2005-06-02 at 15:57 +1000, Ross Johnson wrote:
> > Vlad,
> >
> > In ptw32_mcs_flag_set, can I add a check to avoid calling SetEvent(-1)?
> > I.e.:
> >
> > if (0 != e && -1 != e)
> > {
> > ...
> >
> > Ross
> >
>
> Although, it looks like there can only be one call to ptw32_mcs_flag_set
> for any one flag. But is it always the case?
MCS locks guarantee that the there is one and only one thread setting the flag (for the 'ready' flag: the thread that owns the lock; for the 'next' flag: the next thread in the queue) and there is one and only one thread waiting on the flag (for the 'ready' flag: the next thread in the queue; for the 'next' flag: the previous thread in the queue). Because of this property we do not need to check the flag for -1. Note also that if MCS locks allowed multiple threads to wait for or signal the same event, we would not be able to close the event handle without a race condition. Basically we would be back facing exactly the same problem we had with the reference counting versions.
>
> Also, in pthread_once - don't we still need some acquire/release fences
> when reading/setting 'done'?
MCS locks were meant to work similar to mutexes. I.e., once a critical section is protected by a lock one does not need memory fences inside the section because the 'acquire' and 'release' routines take care of these. All of the interlocked routines plus SetEvent and WaitForSingleObject inside the 'acquire' and 'release' routines have semantics of full memory barriers.
What have we decided regarding the license?
Regards,
--vlad
>
> if (!once_control->done) // <<< Here
> {
> pthread_cleanup_push(ptw32_once_on_init_cancel, (void *)&node);
> (*init_routine)();
> pthread_cleanup_pop(0);
>
> once_control->done = PTW32_TRUE; // <<< and here?
> }
>
> ptw32_mcs_lock_release(&node);
> }
>
> Ross
>