Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #921

Re: The threading specs in the standard: a new catastrophe

Cross-posted to 3 groups.

Show key headers only | View raw

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.

Back to comp.unix.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: The threading specs in the standard: a new catastrophe jameskuyper <jameskuyper@gmail.com> - 2011-07-07 15:25 -0700
  Re: The threading specs in the standard: a new catastrophe sfuerst <svfuerst@gmail.com> - 2011-07-07 16:12 -0700
    Re: The threading specs in the standard: a new catastrophe James Kuyper <jameskuyper@verizon.net> - 2011-07-07 22:41 -0400
    Re: The threading specs in the standard: a new catastrophe "Chris M. Thomasson" <cristom@charter.net> - 2011-07-08 12:47 -0700
      Re: The threading specs in the standard: a new catastrophe sfuerst <svfuerst@gmail.com> - 2011-07-08 13:11 -0700
        Re: The threading specs in the standard: a new catastrophe "Chris M. Thomasson" <cristom@charter.net> - 2011-07-08 16:56 -0700
        Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-09 23:55 +0200
          Re: The threading specs in the standard: a new catastrophe sfuerst <svfuerst@gmail.com> - 2011-07-09 18:40 -0700
  Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-08 01:16 +0200
    some sane words, for sure "Greg A. Woods" <woods@robohack.org> - 2011-07-07 18:33 -0700
    Re: The threading specs in the standard: a new catastrophe jameskuyper <jameskuyper@gmail.com> - 2011-07-08 08:34 -0700
      Re: The threading specs in the standard: a new catastrophe sfuerst <svfuerst@gmail.com> - 2011-07-08 10:47 -0700
        Re: The threading specs in the standard: a new catastrophe James Kuyper <jameskuyper@verizon.net> - 2011-07-09 06:57 -0400
          Re: The threading specs in the standard: a new catastrophe Alexander Terekhov <terekhov@web.de> - 2011-07-09 13:59 +0200
            Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-09 14:45 +0200
            Re: The threading specs in the standard: a new catastrophe "Chris M. Thomasson" <cristom@charter.net> - 2011-07-10 15:47 -0700
              Re: The threading specs in the standard: a new catastrophe Alexander Terekhov <terekhov@web.de> - 2011-07-11 13:38 +0200
            Re: The threading specs in the standard: a new catastrophe Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-11 16:12 +0300

csiph-web