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, or in public headers
where it might force C99, or in structures where strict packing is required.
That said...
For uses where the value appears on the stack or as a function return,
or is a member of a structure that is protected by other schemes (such
as the entire structure only being accessed under management of a lock),
I think the C99 bool type might have significant benefits. Roland has
made the case to me that use of this can result in substantial
improvements in code size and performance, based on tests he's performed
with the ksh93 and AST code. (For example, on some platforms the
compiler can just directly test a status bit in a machine word without
performing a subtraction to compare against zero.)
-- Garrett
>
> Peter
>
> On 08/10/09 19:35, Garrett D'Amore - sun microsystems wrote:
>> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
>> This information is Copyright 2009 Sun Microsystems
>> 1. Introduction
>> 1.1. Project/Component Working Name:
>> sys/stdbool.h
>> 1.2. Name of Document Author/Supplier:
>> Author: Garrett D'Amore
>> 1.3 Date of This Document:
>> 10 August, 2009
>> 4. Technical Description
>> I am sponsoring this fast track for Roland Mainz. The case times out
>> in one
>> week (8/19/2009), and minor binding is requested.
>>
>> -- Garrett
>>
>> 1. Introduction
>>
>> This case a new header <sys/stdbool.h> to allow kernel code
>> to use the C99 datatype "bool" and the associated values
>> "true" and "false".
>>
>> The committment level of these interfaces is "Committed".
>>
>> The release binding is "minor".
>>
>> 2. Discussion
>>
>> We need to move <stdbool.h> to <sys/stdbool.h> (and create a new
>> <stdbool.h> which sources <sys/stdbool.h>) that (new [2]) kernel
>> code can use the new C99 datatype "bool" ([1]) ?
>>
>> [1]="bool" differs from the traditional kernel-land "boolean_t"
>> datatype that it is smaller (e.g. |sizeof(boolean_t)==sizeof(int)|
>> vs. |sizeof(bool)==1|) and optionally allows the compiler to do
>> better optimisations on this datatype (since it is allowed to
>> assume that it only contains "true" and "false" as values instead
>> of the full range from |INT_MIN|-|INT_MAX| for "boolean_t" (since
>> this |enum| is treated as |int| by value-range optimisations))
>> and usually reduces the size of executables (see CR #6870093).
>>
>> [2]=Note that we do not intend do force developers to replace
>> "boolean_t" in existing code, only allow that new code or changes
>> (optionally) can use this C99 feature.
>>
>> 3. Interface table
>>
>> Interface | committment level
>> -----------------------------------------------+------------------
>> <sys/stdbool.h> | Commited
>> C99 datatype "bool" | Commited
>> C99 value "true" | Commited
>> C99 value "false" | Commited
>> C99 CPP symbol "__bool_true_false_are_defined" | Commited
>>
>> Notes:
>> 1. <sys/stdbool.h> precisely implements the functionality for
>> <stdbool.h> defined in IEEE Std 1003.1-2001.
>> 2. The ability to undefine and redefine the macros "bool",
>> "true", and "false" is an _implementation_detail_ in the ISO C
>> standard which may be withdrawn in a future version of the
>> standards specifications, kernel code shall _not_ rely on this
>> _implementation_detail_ (e.g. "#undef true", "#undef false",
>> "#undef bool" are not allowed in kernel code as they may cause
>> problems with future compiler versions).
>>
>> 4. References
>> - Bugster CR #6870093 RFE: C99 <stdbool.h> should be visible for
>> kernel modules
>> - IEEE Std 1003.1-2001
>> - http://en.wikipedia.org/wiki/Stdbool.h
>> - ISO C99 draft (final document is not available for free)
>> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
>>
>> 5. Manual page differences
>>
>> None required.
>>
>> 6. Resources and Schedule
>> 6.4. Steering Committee requested information
>> 6.4.1. Consolidation C-team Name:
>> ON
>> 6.5. ARC review type: FastTrack
>> 6.6. ARC Exposure: open
>>
>>
