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: TaskManager requirements
Date Sun, 18 Jul 2010 23:52:14 GMT
I like your solution, much better.  This might help me to solve another 
problem I'm experiencing with JoinManager and the ZRegisterStorm qa test 
at the moment.

Bit short on time lately, I've been helping my Son rebuild the 
independent suspension on his 1977 Jag, got it back on the road last 
night, sweet ride, smooth & quiet.



Patricia Shanahan wrote:
> On 7/18/2010 12:13 PM, Peter Firmstone wrote:
>> Patricia Shanahan wrote:
>>> I have questions about the TaskManager remove(Task) method. Trying to
>>> end work by any means other than run to completion is always a bit
>>> tricky.
>>> In the event of a remove call for an active Task, TaskManager issues
>>> an interrupt unless the call is in the task's thread. It also removes
>>> the Task from its bookkeeping.
>>> In the current implementation, removal from the ArrayList immediately
>>> stops the removed task from blocking later tasks that need to runAfter
>>> it. That can let a dependent task start running before the removed
>>> task notices the interrupt. That could be bad if, for example, they
>>> share data that is being protected through the runAfter system.
>> Perhaps a hashmap might be used to store tasks that are pending removal,
>> so they can be left on the queue until the removed task has been
>> interrupted?
> Actually, there is no need for an additional data structure. Document 
> a requirement that a Task run method should complete ASAP after an 
> interrupt. During a remove call, if the task is running just send it 
> an interrupt, but leave it in the same data structure(s) as any 
> running task. If and when its run method completes, clean it up from 
> its thread's run method in the normal way.
> There are a couple of arguments in favor if this approach:
> 1. If it goes wrong, the nature of the problem will be obvious in a 
> debugger. I can even help out debug by associating a flag with the 
> Task indicating it has been interrupted.
> Contrast this with the other failure case. If I remove a task before 
> its run method completes, a later task that should have run after it 
> may run in parallel, resulting in a corrupted data structure. In the 
> worst case, neither notices the problem, but ten minutes later some 
> other piece of code that works with the same data structure fails 
> because of the corruption. Such things can be hard to debug.
> 2. It will be more similar to current behavior, making it less likely 
> to cause problems in existing code. As described in my e-mail 
> "TaskManager single thread bottleneck", many of the interesting cases 
> may be running, much of the time, with one worker thread per 
> TaskManager. In that case, no other task can run until the removed 
> task's run method completes, because the removed task holds the only 
> thread.
> If I were to fix the single thread bottleneck but leave the remove 
> behavior unchanged, some uses of TaskManager might see a task start 
> running before the removed task has completed for the first time.
>>> The other issue is that a task that ignores the interrupt can keep 
>>> possession of its thread, indefinitely, despite a remove call. Since 
>>> we only create a bounded number of threads, that could effectively 
>>> kill the TaskManager. To what extent are TaskManager instances 
>>> shared by tasks whose run methods don't have the same trust 
>>> characteristics?
>> Currently TaskManager is only used internally, so the trust should be 
>> the same between tasks, although I like the idea of a singleton 
>> TaskManager and did mention it earlier, that doesn't suit the current 
>> implementation.  We could put an AccessController permission check in 
>> TaskManager before a task is placed into the queue?
> Or make it the responsibility of the code that creates and manages a 
> TaskManager instance to ensure that the mix of tasks is appropriate, 
> and any needed AccessControl checks have been done?
> Patricia

View raw message