(j3.2006) Lock variables

[Van Snyder]

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.

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.