Re: pthread library related

[Charles Cui <charles.cui1984%gmail.com@localhost>]

No, using atomic_inc / atomic_dec for p_nsem  is wrong!

Let's think about the multithreading case. Let's use 2 threads A and B in
the same process as an example.  Assume p_nsem is not reaching the limit,
but only one slot is left.
A and B will each read the p_nsem separately. There will be probability
that they both find
there is one remaining slot. And each of them will increase p_nsem by one
using atomic_inc, the results are we have 1 slot overused, but the error is
never detected.


2016-05-30 12:28 GMT-07:00 Christos Zoulas <christos%zoulas.com@localhost>:

> On May 30,  8:29pm, martin%duskware.de@localhost (Martin Husemann) wrote:
> -- Subject: Re: pthread library related
>
> | Do we really need this? Why is it a function pointer?
>
> It is the same as signal.
>
> | > The third one is the missing kernel logic for _SC_SEM_NSEMS_MAX.
> |
> | Why not use atomic_inc/atomic_dec for the p_nsem count (and a proper
> | atomic-friendly type instead of uint)? Why limit the number at all?
>
> Sure.
>
> christos
>