Subj : Re: reliability of setting thread priority
To   : comp.programming.threads
From : Alexander Terekhov
Date : Fri Feb 25 2005 04:30 pm


gottlobfrege@gmail.com wrote:
[...]
> Basically, if I understand everything correctly, what I take away as
> most important is that you have minimized the use of the named mutex to
> be needed ONLY in the case of a contention, whereas I was going to be

Only to serialize init. That's what DCSI is about. BTW, I had a 
copy&paste error in the previous posts. First check needs msync::acq.

  auto_reset_event & DCSI() {
    auto_reset_event * retry_event;
    if ((retry_event = m_retry_event.load(msync::acq)) == 0) {
      named_windows_mutex_trick guard(this);
      if ((retry_event = m_retry_event.load(msync::none)) == 0) {
        retry_event = new auto_reset_event()
        m_retry_event.store(retry_event, msync::rel);
        m_lock_status.store(-1, msync::rel);
      }
    } 
    return *retry_event; 
  } 

But you can get rid of a mutex and use DCCI variation instead.

  auto_reset_event & DCCI() {
    auto_reset_event * retry_event;
    if ((retry_event = m_retry_event.load(msync::acq)) == 0) {
      if (!m_retry_event.attempt_update(0, retry_event = new 
            auto_reset_event(), msync::rel)) {
        delete retry_event;
        retry_event = m_retry_event.load(msync::acq);
      }
      else
        m_lock_status.store(-1, msync::rel);
    } 
    return *retry_event; 
  } 

The only problem is that Win95/i386 doesn't have CAS for that
attempt_update() with original IBM style bool interface above.

[...]
> why do we need things like this (and PTHREAD_ONCE_INIT, etc)?  I
> thought the language ensured that global statics were initialized to 0?

Yes, but other implementations may need something nonzero or even some
nonportable implementation specific "magic" that gets hidden by macros.

regards,
alexander.

.