[drmaa-wg] Simultaneous waits on the same job id?

[Rajic, Hrabri]

There is an ability to discard the reaped info in synchronized call due to memory constraints.  It is neither ignore nor reap, but dispose, so you lose it.

The reasoning for multithreaded library use went along the lines of users doing their own thread synchronization.   Their flexibility was on our minds at that time, so we wanted a simple semantics attached to the routines. 

The way we saw it at that time, reaped info would be global data and therefore only thread would get to it.  

If a thread wants to reap it own jobs that would work fine also.   

Reaping the same info by multiple threads is definitely useful, but was not a preferred semantics by the participants at the time.  

A bit of history ... I hope it helps

Hrabri
 

>-----Original Message-----
>From: owner-drmaa-wg at ggf.org [mailto:owner-drmaa-wg at ggf.org] On Behalf Of
>Daniel Templeton
>Sent: Monday, June 26, 2006 8:36 AM
>To: Ed Baskerville
>Cc: DRMAA Working Group
>Subject: Re: [drmaa-wg] Simultaneous waits on the same job id?
>
>Ed,
>
>What Andreas is trying to get at is that since synchronize() doesn't
>return job information, so multiple simultaneous synchronize() calls
>will all succeed.  Even if synchronize() reaps job info, since other
>calls to synchronize() don't care whether they actually are able to find
>the job info, it's all good.  As long as synchronize() is running,
>reaped jobs are viewed as simply having ended, so not even a call to
>wait() will cause a call to synchronize() to fail.
>
>Is that really correct?  Can anyone else confirm?  I think we should
>probably have a tracker to clarify that point in the (g2) spec.
>
>Daniel
>
>Andreas.Haas at Sun.COM wrote:
>> On Fri, 23 Jun 2006, Ed Baskerville wrote:
>>
>>> OK, I'll do that. But one more question: how do these issues apply to
>>> synchronize? Consider the following sequence:
>>>
>>> thread 1: wait(job id 5)
>>> thread 2: synchronize(job ids 5,6,7)
>>> [job id 5 finishes]
>>> ¿thread 2 synchronize call fails?
>>> [job id 7 finishes]
>>> [job id 6 finishes]
>>> ¿thread 2 synchronize call succeeds?
>>>
>>> Should synchronize fail with INVALID_JOB as soon as any of the ids
>>> it's waiting on are reaped? Or should it eventually succeed?
>>
>> There is no reason for synchronize to fail, as long as none of the
>> jobs was reaped when synchronize() gets issued.
>>
>> Andreas