> > 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.
Does this mean that on a potentially SMP hppa just an unlocked aligned word load can produce invalid data? The HP's reference seems to be 'unavailable'... > 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. Why was the splhigh() there in the first place? I thought that on i386 and the like, AND to a memory location isn't atomic (without the LOCK prefix) and therefore other thread reading the value might read garbage. Whereas MOV is ok. Obviously, sane architectures doing LD, AND and ST are ok as well, as long as the ST is atomic (I don't have any experience with hppa and random search on the internet suggested that pa-riscs do have word stores atomically). -- Martin Pelikan
