Re: tutorial draft checked in

["Frank Ch. Eigler" <fche@redhat.com>]

Hi -

hunt wrote:

> >This operation is efficient (taking a shared lock) because the
> >aggregate values are kept separately on each processor, and are only 
> >aggregated across processors on request.
> 
> Surprised me. I checked and this accurately described the current
> implementation, but the shared lock is unnecessary and should probably
> not be mentioned.
> [...]

This is the subject of bug #2224.  The runtime is taking locks, and
the translator is also emitting locks.  In my opinion, the runtime
should leave the maximum possible locking discretion to the
translator, since e.g. only the latter knows how to enforce locking
timeouts over contentious data.

There happens to be a small potential advantage to one technique the
runtime uses for pmap locking.  Instead of a single rwlock (which
concurrent <<< thread would all take in shared mode), it uses per-cpu
spinlocks (which each <<< thread can take without sharing with other
<<< users).  (On the flip side, a @op thread has to lock all spinlocks
in a loop, instead of just taking the rwlock in exclusive mode,
risking a little incoherence if this is done in the wrong order.)

Anyway, if the advantage of having unshared per-cpu locks for the <<<
case was large, the translator could adopt the technique just as
easily.

- FChE