On Sat, 05 Apr 2014 15:56:52 GMT, Jack Applegame wrote:
In other words. in single-threaded configuration, task never yields and locks the mutex again and again, if there are no blocking operations between unlocking and locking. Even if thousand others tasks are waiting for the mutex.
Looks strange for me, because trying to lock the mutex is a blocking operation and should force task to yiled if mutex is unlocked and other tasks already waiting.
Yes, but usually you have some activity on that task like packets going in or out, sleeps occurring, events being waited for. These all happen to yield the task, and when it's done the tasks are finished. It may be preferable to sleep outside of your lock to simulate these events. For anything that involves heavy compute like image or video rendering, you're better off using a new thread or process and avoiding putting it in tasks altogether, or you might block your i/o event loop (ie. webserver).