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 <chris...@zoulas.com>: > On May 30, 8:29pm, mar...@duskware.de (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 >
