On Sat, 05 Apr 2014 04:42:52 GMT, Jack Applegame wrote:
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?
Asking if it's the planned behavior of a mutex comes down to checking if this is really how a mutex works. I've read enough about the subject to answer that yes, this is the planned behavior - unless vibe.d has a hidden agenda. The reason you're seeing this problem is because the planned behavior covers heavy i/o, not heavy CPU (unless you yield frequently). This is a problem that I've been exploring right now - a solution would be to use a compute proxy thread with a dedicated task pool, which would be great for a thread-blocking operation that involves some i/o as well.