On 4/21/21 7:02 PM, Alexander Monakov wrote:
> On Wed, 21 Apr 2021, Tom de Vries wrote:
> 
>>> I don't think implementing futex_wait is possible on nvptx.
>>>
>>
>> Well, I gave it a try, attached below.  Can you explain why you think
>> it's not possible, or pinpoint a problem in the implementation?
> 
> Responding only to this for now. When I said futex_wait I really meant
> Linux futex wait, where the API is tied to a 32-bit futex control word
> and nothing else. Your implementation works with a gomp_barrier_t that
> includes more than one field. It would be confusing to call it a
> "futex wait", it is not a 1:1 replacement.
> 
> (i.e. unlike a proper futex, it can work only for gomp_barrier_t objects)

Ah, I see, agreed, that makes sense.  I was afraid there was some
fundamental problem that I overlooked.

Here's an updated version.  I've tried to make it clear that the
futex_wait/wake are locally used versions, not generic functionality.

The main change in structure is that I'm now using the
generation_to_barrier trick from the rtems port, allowing linux/bar.c to
be included rather than copied (because the barrier argument is now
implicit).

Furthermore, I've reviewed the MEMMODELs used for the atomic accesses,
and updated a few.

Also now the cpu_relax from doacross.h is used.

Thanks,
- Tom