Am 05.04.2014 06:42, schrieb Jack Applegame:
On Sat, 05 Apr 2014 03:43:07 GMT, Etienne Cimon wrote:
The mutex here is a wall that forces other tasks to yield when trying to lock it (whatever the thread they're in). Once the lock is freed, the waiters are notified and resumed at the next run of the event loop.
However, this seems to happen within a single thread and your first task blocks this thread because it's in an infinite loop. Leaving a synchronization scope shouldn't force a task to yield because even though a context switch is very light, it shouldn't be abused. You may see a difference if you actually include some multi-threading into the equation using runWorkerTask.
I know how mutex works. My main question: is it planned behavior or is it necessary to fix?
My first idea was in line with Etienne that the behavior in this case is
expected in the sense that it's "implementation dependent". Everything
else would potentially incur an overhead in many places where this isn't
necessary. Also it would mean that then the "unlock" operation would
also be "blocking", which can be very counter intuitive.
On the other hand I see that this may cause a very unexpected and hidden
kind of bug, which may actually be a pretty strong counter argument. How
bad was your experience with it in this case?
On the other hand it's a good indicator for practically serial code that
possibly should architecturally be running in the same task to save the
overhead of a mutex in the first place.