Sebastian Lackner sebastian@fds-team.de writes:
- Its also on purpose, that num_workers is (read-) accessed at one point
without locking the critical section. If num_workers > 0 we can be sure, that a worker thread will process the work item (sooner or later). If num_workers == 0 we enter the critical section, and check once more to prevent race condition 2.
The worker may be about to exit at the time you check. I don't think it makes any sense to add races to "optimize" an error case that's not going to happen anyway.
[Sorry for the duplicate Alexandre, clicked the wrong button and didn't answer to the mailing list :( ^^]
No, the worker cannot exit at the time when the variable is checked. A worker only can break out of the processing loop, when there is no new item and the condition variable timeout expires. Since the new item was added before the check (while holding the CS), the last worker cannot terminate before this element has been processed and the additional delay of 30sec to wait for new jobs.
Nevertheless I understand that its probably a bit too much "optimized", so I'll submit a new patch later which simplifies this part a bit.
Regards, Sebastian
2014-03-11 15:09 GMT+01:00 Alexandre Julliard julliard@winehq.org:
Sebastian Lackner sebastian@fds-team.de writes:
- Its also on purpose, that num_workers is (read-) accessed at one point
without locking the critical section. If num_workers > 0 we can be sure,
that
a worker thread will process the work item (sooner or later). If num_workers == 0 we enter the critical section, and check once more to prevent race condition 2.
The worker may be about to exit at the time you check. I don't think it makes any sense to add races to "optimize" an error case that's not going to happen anyway.
-- Alexandre Julliard julliard@winehq.org
-
Alexandre Julliard -
Sebastian Lackner