From: vkliatchko@optonline.net
To: Ross Johnson <ross.johnson@homemail.com.au>
Cc: Gottlob Frege <gottlobfrege@gmail.com>,
Pthreads-Win32 list <pthreads-win32@sources.redhat.com>
Subject: Re: RE: New pthread_once implementation
Date: Thu, 02 Jun 2005 12:59:00 -0000 [thread overview]
Message-ID: <a091c8a08825.a08825a091c8@optonline.net> (raw)
> -----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
>
reply other threads:[~2005-06-02 12:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a091c8a08825.a08825a091c8@optonline.net \
--to=vkliatchko@optonline.net \
--cc=gottlobfrege@gmail.com \
--cc=pthreads-win32@sources.redhat.com \
--cc=ross.johnson@homemail.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).