(j3.2006) Lock variables

[Bill Long]

Van Snyder wrote:
> On Mon, 2009-03-09 at 17:41 -0700, Malcolm Cohen wrote:
>   
>> Van Snyder wrote:
>>     
>>> For now,
>>> it would just be a silly program that locks a noncoarray lock -- until
>>> we implement task parallelism, at which time it will make sense.
>>>   
>>>       
>> It seems highly likely to me that the data structure and locking 
>> mechanism needed for a task lock and that needed by a coarray lock would 
>> very likely be significantly different, probably to the extent that 
>> providing a single lock type that does both jobs would perform 
>> significantly worse than either kind.  The same applies to critical 
>> sections.
>>
>> Certainly if by task parallelism you mean running in the same address 
>> space (i.e. within a single image) I wouldn't build task locks on top of 
>> coarray locks, or indeed much of the task parallel infrastructure on any 
>> of the coarray parallel infrastructure.  Maybe that's just me though.
>>     
>
> This is precisely why I advocated in 08-202 to spell LOCK as COLOCK and
> UNLOCK as COUNLOCK and LOCK_TYPE as COLOCK_TYPE and CRITICAL as
> COCRITICAL, so that when (if ever) we want the same beasts for task
> parallelism but with different underlying mechanisms, we don't need to
> spell them NONCOLOCK, NONCOUNLOCK, NONCOLOCK_TYPE and NONCOCRITICAL.  A
> straw vote (1-6-2) decided this wasn't necessary.  See 08-274.
>   

I agree the Malcolm that the implementation characteristics of locks for 
images and local threads would most likely be different.  I don't think 
anyone would go for names like NONCOLOCK (assuming we ever go this 
route). More reasonable options, like TLOCK (thread lock), would 
probably be proposed.

Cheers,
Bill
 
> OTOH, if we do task parallelism less like pthreads and more like Ada
> does it (see "Real time and concurrent programming in Ada" by Burns and
> Wellings) but without the special facilities for timing that real-time
> software needs, we won't need locks and critical sections.
>
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>   

-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120