Zitat von Gaetano Mendola
On 08/10/2010 05:05 PM, Roland Bock wrote:
On 08/10/2010 04:28 PM, Stefan Strasser wrote:
isn't that a waste? Why make reader 3 and 4 waiting and then make those running before the writer? The code to reproduce that is at the end.
I don't think Boost.Thread specifies this behaviour, so it is probably platform-dependent. I'm guessing readers 3 and 4 have to wait because the writer thread requested an exclusive lock (and otherwise the writer thread would be starved), but once all locks have been released it is a decision of the OS scheduler which thread is then woken up first and can acquire a lock - one of the reader threads in this case apparently.
Right, if you want an "order preserving shared mutex", you have to write it yourself.
That was clear to me, still I think, I don't know who fault is, having a reader waiting and then being scheduled is a waste :D
I guess I'll write one my self.
don't you need OS support for this kind of scheduling? I guess you can write a mutex in userspace that only "preserves order", but as long as you still want threads to be scheduled based on workload/time slices Í think you need an OS scheduler supporting shared mutexes to improve this situation.