Zitat von Gaetano Mendola
Hi all, I'm in need to have a reader/writer mutex with no starvation (I'd say a fair mutex), before to make a my own implementation I have checked the boost one to see if it makes starvation or not, and I'm a bit puzzled about the behave:
I'm experiencing this:
reader 1 start ... writer 1 running ... reader 2 start ... writer 2 running ... writer 1 start << blocked reader 3 start << blocked reader 4 start << blocked
until now it seems that reader 3 and reader 4 are waiting because there is a writer waiting and then the writer will run before reader 3 and 4, unfortunately this is not the case, the execution continues like this:
reader 1 ends reader 2 ends ... writer 3 running ... ... writer 4 running ... reader 3 ends reader 4 ends ... writer 1 running ... writer 1 ends
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.