Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Alexander Terekhov <terekhov@web.de>
Newsgroups: comp.std.c,comp.programming.threads,comp.unix.programmer
Subject: Re: The threading specs in the standard: a new catastrophe
Date: Sat, 09 Jul 2011 13:59:05 +0200
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <4E184289.9D95CABB@web.de>
References: <iv422a$33k$1@speranza.aioe.org> <iv576t$2lm$1@dont-email.me> <iv58m6$5vo$1@speranza.aioe.org> <4e53ba11-fea9-4896-8bb9-6b45acb6e18f@y24g2000yqb.googlegroups.com> <iv5ep3$it3$2@speranza.aioe.org> <3de2d9ab-e52a-4eb3-a726-b5bed4ce7eef@q1g2000vbj.googlegroups.com> <a4b696f0-5d1a-4e7a-8988-981c82a89969@e18g2000vbx.googlegroups.com> <iv9c77$5dj$1@dont-email.me>
Reply-To: terekhov@web.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: mx04.eternal-september.org; posting-host="MCbSEzW5qwGLFMNXJh39IQ"; logging-data="25303"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/jfU+3GbofCZEdKrhWHZMnAVa8Prsle+k="
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
Cancel-Lock: sha1:DQMdBuNwJAOqx1PzJ0ReQglsgVo=
Xref: x330-a1.tempe.blueboxinc.net comp.std.c:681 comp.programming.threads:408 comp.unix.programmer:921


James Kuyper wrote:
> 
> On 07/08/2011 01:47 PM, sfuerst wrote:
> ...
> > This is incorrect.  There are multiple libraries implementing the
> > posix threading library for the Microsoft windows platform.  None of
> > them have difficulty supporting the fact that posix mutexes require
> > the possibility of static initialization.  A simple google search for
> > "pthread windows" will give examples of how to do it.
> 
> On 2011-07-07, in c.l.c, c.p.t, and c.u.p, in a message with the subject
> "POSIX threads hard to implement in Windows", William Ahern wrote:
> ...
> > But anyone who has used POSIX threads and Windows' native API quickly learns
> > that they're quite different approaches. The biggest difference that I'm
> > aware of is that Windows' mutexes cannot be statically initialized.
> 
> Unless I'm misunderstanding something, which is quite possible, you and
> he appear to be in disagreement on this point. If so, could the two of
> you discuss this issue and resolve that disagreement?

sfuerst is right, a la pthread statically initialized mutexes are no
problem under Windows native API, e.g.:

#define SWAP_BASED_MUTEX_FOR_WINDOWS_INITIALIZER { 0, 0 } 

class swap_based_mutex_for_windows { 

  /* ... */ 

  // -1: free, 0: locked, 1: contention 

  atomic<int>                m_lock_status;   
  atomic<auto_reset_event *> m_retry_event;  // Windows bin semaphore 

  /* ... */ 

  void lock() { 
    if (m_lock_status.swap(0, mem::acquire) >= 0) 
      slow_lock(); 
  }   

  void unlock() { 
    if (m_lock_status.swap(-1, mem::release) > 0) 
      m_retry_event.load(msync::none)->set(); 
  } 

  void slow_lock() { 
    auto_reset_event & retry_event = DCSI(); 
    while (m_lock_status.swap(1, mem::acquire) >= 0) 
      retry_event.wait(); 
  } 

  auto_reset_event & DCSI() { 
    auto_reset_event * retry_event; 
    if (!(retry_event = m_retry_event.load(mem::acquire)) { 
      named_windows_mutex_trick guard(this); 
      if (!(retry_event = m_retry_event.load(mem::non_competing))) { 
        retry_event = new auto_reset_event();
        m_retry_event.store(retry_event, mem::release); 
        m_lock_status.store(-1, msync::release); 
      } 
    } 
    return *retry_event; 
  } 
} 

The tricky part is to make slow_lock() not fail due to "new
auto_reset_event()" failure... but that is solvable as well using
fallback to a single preinitialized event count, effectively turning
binsema's set() into eventcount's broadcast().

regards,
alexander.