public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
* Re: RE: New pthread_once implementation
@ 2005-06-02 12:59 vkliatchko
  0 siblings, 0 replies; only message in thread
From: vkliatchko @ 2005-06-02 12:59 UTC (permalink / raw)
  To: Ross Johnson; +Cc: Gottlob Frege, Pthreads-Win32 list



> -----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
> 


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2005-06-02 12:59 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-06-02 12:59 RE: New pthread_once implementation vkliatchko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).