[drmaa-wg] drmaa_wait() Clarification

[Rajic, Hrabri]

Everything was clear the first time around ... and I do agree there is
an opportunity for that one and similar cases could be better handled.

First, let us extend the situation to more wait requests; many of them
and/or of different sorts, and then let us see how to approach solving
this problem. 

    -Hrabri
 

-----Original Message-----
From: owner-drmaa-wg at ggf.org [mailto:owner-drmaa-wg at ggf.org] On Behalf
Of Daniel Templeton
Sent: Monday, January 24, 2005 9:53 AM
Cc: DRMAA Working Group
Subject: Re: [drmaa-wg] drmaa_wait() Clarification

I think I'm still not making myself clear.  Here's the scenario I'm 
asking if we support (or why we don't):

1) Thread 1 does drmaa_wait("1", -1)
2) Thread 2 does drmaa_wait("1", -1)
3) Job 1 ends
4) DRMAA sends exit status and resource usage to Thread 1
5) DRMAA sends exit status and resource usage to Thread 2
6) DRMAA reaps the info for job 1 (only once)
7) Threads 1 and 2 return from drmaa_wait() calls

Two threads concurrently call drmaa_wait for the same job.  Both get the

exit info, and DRMAA only reaps the info once.

Daniel

Rajic, Hrabri wrote:

> Thinking about it a little further, I can see where you might have 
> wanted the spec to say that, but I don't think it's clear.  The spec 
> says that all calls subsequent to a *successful* call get an error.
In 
> the case below, neither is successful until step three, and then it's 
> arguable as to whether the second call is subsequent to the first
call's
> 
> success or not.
> Regardless, my point is that we need to make it clear in the spec, 
> whatever we decide it should say.
> 
> So, is there a reason why the spec is supposed to say that two 
> concurrent calls can't both succeed?  That sounds very limiting, and I

> completely fail to see the advantage.  You can't tell me that it's for

> ease of implementation, after the weeks of work I put into
implementing 
> the PartialTimestamp class.
> 
> 	Memory issues for large number of submitted job situations led
> us to 
> 	specify reaping only once semantics.
> 
> 		Hrabri
> 
> Daniel