Subj : Re: reliability of setting thread priority
To   : comp.programming.threads
From : gottlobfrege
Date : Fri Feb 25 2005 03:01 pm


Alexander Terekhov wrote:
> [...]
>
> #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;
>
>   /* ... */
>
>   void lock() {
>     if (m_lock_status.swap(0, msync::acq) >= 0)
>       slow_lock();
>   }
>
>   void unlock() {
>     if (m_lock_status.swap(-1, msync::rel) > 0)
>       m_retry_event.load(msync::none)->set();
>   }
>
>   void slow_lock() {
>     auto_reset_event & retry_event = DCSI();
>     while (m_lock_status.swap(1, msync::acq) >= 0)
>       retry_event.wait();
>   }
>
>   auto_reset_event & DCSI() {
>     auto_reset_event * retry_event;
>     if ((retry_event = m_retry_event.load(msync::none)) == 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;
>   }
>
> }
>
> regards,
> alexander.

So I misread this the first time.  I was thinking the lock started as
free, but it does not, it starts as locked.  So the first one in does
the DCSI.  Would it be possible to start unlocked, and have the '2nd'
one in (ie first contention actually) do the slow_lock, create the
event, etc?  (And unlock only sets the event if it exists - ie if there
is contention?)

That's how I originally read it, which made me think it was really
great.  And it was close to working (by my reading).  Then I saw some
problems (in my misreading), so I can imagine that creating the event
on first contention might not be possible.  So I guess now I don't
think it is great, just good. :-)

And I'm back to having a mutex created/locked/destroyed on each object
at least the first time in. But not on subsequent locks.  Subsequent
locks are fast.  Hmmm.

Tony.

.