> Date: Wed, 19 Jun 2013 13:40:19 +0200
> From: Martin Pelikan <martin.peli...@gmail.com>
>
> > If you're right that atomic_{clear,set}bits_int is correct and
> > sufficient and actually faster, then all dynamic executables would
> > benefit from this speedup (sigprocmask is used in ld.so(1)).
>
> Since on i386 GENERIC these atomic_* things don't emit the LOCK prefix,
> performance shouldn't be an issue; I'm actually more worried about this bit:
>
> > > - p->p_sigmask = mask &~ sigcantmask;
> > > + p->p_sigmask = mask;
>
> On the right architecture where a word store isn't atomic enough and
> with the right compiler that decides to put p_sigmask on an address
> ending with 0xFFF with 4k-sized pages, we have two problems already.
>
> I'm only asking if such a situation can happen, or if there is some
> ensure_this_assignment_is_always_atomic(&p->p_sigmask, mask); function
> that I missed.
There isn't one. Unfortunately, we might need one to support SMP on
hppa, where we have the emulate atomic operations using a lock. In
fact you need to worry about reading as well. And since ptsignal()
looks at the p_sigmask of other threads in the process, it is not
immediately obvious there isn't a problem here.
I think the fact that only the thread itself can change its sigmask
means that there isn't an issue here. But that probably means that
bothering with atomic_setbits_int/atomic_clearbits_int isn't necessary
in the first place.
