Roland Mainz wrote: > Garrett D'Amore wrote: > >> Peter Cudhea wrote: >> >>> It would be useful to take a definitive stand on whether or not >>> operations on two adjacent bool values are atomic with respect to one >>> another. E.g. back in the days of the DEC Alpha, there existed no >>> instructions that could modify the value of one bool in a word without >>> potentially interfering in other uses of a differnt bool in the same >>> word. That consideration does not apply to either of the current >>> Solaris platforms. But are we introducing a constraint that Solaris >>> could never be ported to such a platform? Or are we introducing a >>> constraint that any values that should be updatable atomically should >>> be stored in a boolean_t and not in a bool? Or does the compiler >>> guarantee to allocate bools on word boundaries in platforms such as >>> this? Either way, we should spell it out. >>> >> I would suggest that in situations where this matters, there are a >> couple of options: >> >> 1) use locking primitives to guard an associated group of booleans. >> 2) find out what C99 says about this (if anything) >> 3) if you're really that concerned, such as in kernel space, use boolean_t. >> >> I raised some of these concerns in private review with Roland before >> submitting the case. Personally, I have reservations about using C99 >> bool in places where atomicity is a requirement, >> > > What about adding an |atomic_swap_bool()| (e.g. an alias for > |atomic_swap_uchar()|) to <atomic.h> ? >
Not a bad idea -- if the compiler is guaranteed to ensure that booleans fit in a single word. The concern is that if the boolean value is stored as a component of a larger machine word, that there could then be atomicity issues. I don't think we need to do anything as part of this case though. > >> or in public headers >> where it might force C99, or in structures where strict packing is required. >> > > What do you mean with "strict packaging" in this case ? |bool| will > behave like the platform's smallest datatype (e.g. |char| (one byte on > SPARC+x86)) within a struct and therefore consume a lot less than > |boolean_t| (which may result in less data cache usage since |boolean_t| > is AFAIK an |enum| which consumes the space of an |int| (four bytes on > SPARC+x86)) ... > I mean relying on this in a structure that is meant to be very exact, such as a structure representing on-disk, on-network, or physical device structures. - Garrett > ---- > > Bye, > Roland > >
