609837 - VMPI threading extensions require a yield-like function

Status: RESOLVED FIXED

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Simon Wilkinson]

A non-priority-inverting yield will be very useful for building well-behaved busy-waiting.

Comment 1

[Simon Wilkinson]

Attachment: Initial Patch

Comment 2

[Simon Wilkinson]

Attachment: Latest patch

Comment 3

[Edwin Smith]

Comment on attachment 494807 [details] [diff] [review]
Latest patch

Looking at this as a newcomer, I read the docs on VMPI_yeild(), and wonder what eactly it's good for, given the contract on different platforms is so loose.  

* are there cases where it MUST be used? what are they?
* what is guaranteed to happen, even if implementations vary so much?

Comment 4

[Simon Wilkinson]

(In reply to comment #3)
> Comment on attachment 494807 [details] [diff] [review]
> Latest patch
> 
> Looking at this as a newcomer, I read the docs on VMPI_yeild(), and wonder what
> eactly it's good for, given the contract on different platforms is so loose.  
> 
> * are there cases where it MUST be used? what are they?
> * what is guaranteed to happen, even if implementations vary so much?

A yield is useful within busy-waiting loops.
However, there is no requirement that it *must* be used, except on platforms without a pre-emptive thread scheduler. I understand that all of our platforms do have a pre-emptive scheduler, so its application will only be an optimization.

I'd really like the yield function's contract to be:
Hints to the scheduler that the running thread is waiting on some condition to be updated by another thread, and importantly, that the condition is already fulfilled or will be very soon (i.e. within a scheduling quantum). Hence the running thread should temporarily get out of the way (yield) for the other thread to run. This should not penalize the regular scheduling of either thread, and particularly we want the yielding thread to start running again as soon as possible as it can now make forward progress.

On Windows the SwitchToThread function is close enough to the above idea. All the other platforms aren't particularly clear about when the yielding thread will start running again (getting put to the back of runnable queue is typical).

In most cases you should be using regular wait/notify to synchronize threads in this way. But in some parts of the synchronization implementation itself you cannot, i.e. spin-lock implementation, safepoint wait etc. So the yield is better than nothing.

Comment 5

[Simon Wilkinson]

Attachment: Latest. More docs.

Added some more docs that summarizes my reply to Ed above.

Comment 6

[Simon Wilkinson]

Attachment: Latest with Solaris and WinCE build fixes

Fixes the WinCE build where SwitchToThread() is not available (Sleep(1) is used instead).

Fixes the Solaris build so that the rt library is linked (required for the sched_yield() function)

Comment 7

[Simon Wilkinson]

Attachment: Latest. Rebased to TR-5705

Comment 8

[Simon Wilkinson]

Comment on attachment 499317 [details] [diff] [review]
Latest. Rebased to TR-5705


Requested another SR as I've had to link a new library (rt) in the Solaris build.

Comment 9

[Edwin Smith]

Comment on attachment 499317 [details] [diff] [review]
Latest. Rebased to TR-5705

Is there anything directly testable here, or is usage from upper layers good enough?

Comment 10

[Simon Wilkinson]

(In reply to comment #9)
> Is there anything directly testable here, or is usage from upper layers good
> enough?

The safepoint selftests directly call VMPI_threadYield(), this should be good enough.

Comment 11

[Tamarin Bot]

changeset: 5843:891ad70c3012
user:      [e-mail]
summary:   Bug 609837 - VMPI threading extensions require a yield-like function (a=swilkin,r+kpalacz,sr+edwsmith)

http://hg.mozilla.org/tamarin-redux/rev/891ad70c3012