From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2004-08-09 09:26:09
Howard Hinnant wrote:
> So I believe you could design code at least partly the way you've
> proposed with my current proposal. Although I'm sure I'm not fully
> understanding the write_lock.upgrade_pending() functionality. The way
> I currently have my rw_mutex implemented, this information is not
I know that.
> Actually my current implementation is based on your suggested
> "single entry gate" design. So when the mutex is write locked, it has
> no idea who or if anyone is waiting outside the gate.
You'd need a semaphore, not a mutex for "entry gate". (first
upgrader/writer would lock it and the last one would unlock it).
> I liked the idea
> that the scheduler, not the mutex, decides if a reader or writer gets
Yes, but this scheme has a drawback. "Serial wakes across context
switching" (in addition to locking across context switching). For
alternative, see (for example)
(Subject: Re: rwlock using pthread_cond)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk