Luca Cazzaniga wrote:Thanks a lot for your reply, but I can ask you to enlight me if a specific case is possible.
The sleep method involves the transit of the current (main) thread in wait_timeout for one millisecond (that's ok)
but can't the timeout expire before the scheduler chose the next thread to process?
In that case the scheduler could choose to terminate the main thread before to process the spawned threads being the execusion order not deterministic.
Did the sleep method force an execution order?
Luca Cazzaniga wrote:Hi Harry, sorry for my English..
There are three thread involved in the execution:
the main thread and the two spawned thread (printing a and b)
Is the following sequence of events possible?
main spawns thread t1
thread t1 pass in runnable state (ready)
main goes to sleep for 1 millisecond
the thead main awakes and becomes runnable
the scheduler choose main as running thread
main spawns thread t2
thread t2 pass in runnable state (ready)
main goes to sleep for 1 millisecond
the timeout expires and the thead main awakes (now it's runnable)
the scheduler choose main as running thread
the main terminates
the scheduler chooses t2 as running thread
the scheduler chooses t1 as running thread
I'm not sure about what sleep() is supposed to do, shouldn't it send to sleep only the current thread?
In the explaination it seems to force the scheduler to choose the next ready thread to run at the state translation moment, but isn't it matter of vm scheduler implementation/policies?
Thanks a lot for your time.
It's fun to be me, and still legal in 9 states! Wanna see my tiny ad?
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|