Kaz Kylheku
10/23/2014 6:03:00 PM
On 2014-10-23, Richard Heathfield <invalid@see.sig.invalid> wrote:
> Ramine wrote:
>
>> On 10/21/2014 4:12 PM, Richard Heathfield wrote:
>>> Ramine wrote:
>>>
>>>> The Sleep(0) is on Windows, to give up he time slice.
>>>
>>> That's only necessary if you're running Win9x, and even then only if
>>> you've got a 16-bit application. I suggest you upgrade to a decent
>>> operating system (or, if you prefer, Windows 7).
>>
>> The problem shows on Windows 2008 server too, so i had
>> to use sleep(0) to correct the problem.
>
> Is it your claim, then, that Windows 2008 server uses co-operative
> multitasking rather than pre-emptive?
If Ramine believed that Windows 2008 is cooperative, he would not
use the terminology "give up the time slice", which is not applicable
to cooperative tasking.
If you're tuning the implementation of some locking primitives, you sometimes
need a way to give up a time slice.
Ramine appears to be relying on a documented behavior of Sleep in MSDN:
"A value of zero causes the thread to relinquish the remainder of its time
slice to any other thread that is ready to run. If there are no other threads
ready to run, the function returns immediately, and the thread continues
execution."
Threading primitives on GNU/Linux also used to do the equivalent of Sleep(0) in
their spin-locking loops, until futexes were invented.
If you don't have futexes, and no existing suspension primtive such as a
semaphore is appropriate to your locking algorithm, you may have to rely
on a crude "give up timeslice" operation to avoid burning cycles.
OTOH if you see Sleep(0) in application code, then that is usually a sign that
the developers have run into thread-related situations in the code which they
are trying to band-aid, without knowing entirely what they are doing.