river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: A new implementation of TaskManager
Date Tue, 06 Jul 2010 03:37:37 GMT
Peter Firmstone wrote:
> Patricia Shanahan wrote: .
>> Essentially, this is the usual operating system strategy of putting 
>> threads that are not currently runnable in a data structure 
>> associated with the reason for non-runnability, outside the priority 
>> structure that dispatches runnable threads. This minimizes the cost 
>> to the dispatcher of a thread that cannot do anything useful until 
>> some disk read finishes.

Hmm, this shows problem solving experience, take a learning and reapply 
it to something new. Would this mean that you'd have a dispatch thread 
that checks if the parked tasks are ready?

 Be careful though, a task that has been parked might be depended upon 
by some other task in the queue, that's what I don't like about the 
current implementation, there is no way of knowing that you are checking 
all tasks on the queue unless you lock the queue, and then, how do you 
know your not dependant on some task that is about to be added to the 
TaskManager but is being blocked by holding a lock.  Having said that 
though, the current implementation seems to work, it needs further 
investigation.

You know, task implementation objects could communicate using a static 
atomic integer sequence id, all task objects could use it to determine 
if they are ready to execute, if a task has an object sequence number, 
equal to the sequence id, then it is ready to execute, if less, it could 
throw a sequence exception, if greater, it isn't ready.  The same 
behaviour could be managed by a Group implementation.

Just an idea, don't know if it is relevant to any implementations.
>>
>> This approach has its highest cost if the TaskManager has a lot of 
>> tasks, and we are adding a Task depends on none of them but is of a 
>> type that might depends on another Task, so it has to scan the entire 
>> Iterable.
>>



Mime
View raw message