Patricia Shanahan wrote:
On 7/22/2010 12:10 PM, Gregg Wonderly wrote:
I'm thinking more and more that this runAfter business should really be
a O(1) thing. If runAfter() is implemented to return true, can not that
decision be made at the time of enqueue? It just looks like so much of
this is spread around to so few actual users in the current API. As I
look over the usages, there is some fuzzy logic involved in some cases
where the sequence number is used for ordering. ...
I think some of the sequence number stuff may be OK, but if it is OK it
is probably unnecessarily inefficient.
One of the key things about sequence numbers, is that it lets both the sender
and receiver of such marked data understand the significance of what they have.
TCP uses sequence numbers on the IP datagrams to maintain ordering. It, of
course has retry to get all the pieces that might be missing.
In the case of task manager, it helps asynchronous activity happening on
separate threads, understand how to manage data races such that outcomes can be
predictable no matter how scheduling occurs.
Another way to manage this issue might be possible. But, we will need to look
at some of the specifics in SDM and other classes where a plethora of code paths
exist which can complicate the management of state in other code paths.
Think of the sequence number as a queuing mechanism that is fairly lightweight
compared to separate, explicit queues whose access then becomes a contention
point. And remember that even there was a queue, because of the asynchrony in
the codepaths leading up to the Task creation, it would be difficult to put an
object into a queue without similar ordering issues that some of the code tries
to discover by inspecting various state.
Gregg Wonderly
