[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pthread library related
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
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?
Main Index |
Thread Index |