[Cython] cython.parallel tasks, single, master, critical, barriers

[Robert Bradshaw]

On Wed, Oct 12, 2011 at 1:49 AM, Dag Sverre Seljebotn
<d.s.seljebotn at astro.uio.no> wrote:
> On 10/12/2011 10:36 AM, Dag Sverre Seljebotn wrote:
>>
>> On 10/12/2011 09:55 AM, Robert Bradshaw wrote:
>>>
>>> On Sun, Oct 9, 2011 at 5:57 AM, Dag Sverre Seljebotn
>>> <d.s.seljebotn at astro.uio.no> wrote:
>>>>
>>>> On 10/09/2011 02:18 PM, Dag Sverre Seljebotn wrote:
>>>>>
>>>>> On 10/09/2011 02:11 PM, mark florisson wrote:
>>>>>>
>>>>>> with parallel.critical():
>>>>>> this section of code is mutually exclusive with other critical
>>>>>> sections
>>>>>> optional keyword argument 'name' specifies a name for the critical
>>>>>> section,
>>>>>> which means all sections with that name will exclude each other,
>>>>>> but not
>>>>>> critical sections with different names
>>>>>>
>>>>>> Note: all threads that encounter the section will execute it, just
>>>>>> not at the same time
>>>>
>
> On critical sections, I do feel string naming is rather un-Pythonic. I'd
> rather have
>
> lock_a = parallel.Mutex()
> lock_b = parallel.Mutex()
> with cython.parallel:
>    with lock_a:
>        ...
>    with lock_b:
>        ...
>
> This maps well to pthread mutexes, though much harder to map it to OpenMP...

For this low level, perhaps people should just be using the pthreads
library directly? Here I'm showing my ignorance: can that work with
OpenMP spawned threads? (Maybe a compatibility layer is required for
transparent Windows support.) Suppose one could write a context object
that did not require the GIL, then one could do

with MyContext():
   ...

in a nogil block, MyContext could be implemented by whoever on
whatever thread library, no special language support required.

> So my proposal is:
>
>  a) parallel.Mutex() can take a string argument and then returns the same
> mutex each time for the same string, meaning you can do
>
> with parallel.Mutex("somename"):
>
> which maps directly to OpenMP.
>
>  b) However, this does not make sense:
>
> with parallel.Mutex():
>
> because each thread would instantiate a *seperate* mutex. So raise compiler
> error ("Redundant code, thread will never block on fresh mutex")
>
>  c) However, one can use a default global Mutex instance:
>
> with parallel.global_mutex
>
> (mapping to an un-named critical in OpenMP)
>
> This seems to be simple enough to implement, and allows generalizing to the
> advanced case above later (probably using pthreads/Windows directly).

Alternatively, let parallel.Mutex() be the global mutex, with some
other way of getting a new, unique mutex to pass around and use in
multiple places.

- Robert