How to name a function to indicate that they require calling from acritical section?

[celephicus]

Good programmers know about critical sections, which protect shared resources. Good programmers use descriptive names. I just spent a day tracking down a real-time bug due to me calling a function outside a critical section.

How would you name a function to indicate that it should only be called from within a critical section? Something like doStuff_critical() with the "_critical" telling you the requirement for a critical section. But of course less ugly.

Any ideas?

 

[Eric Sosman]

Good programmers know about critical sections, which protect shared resources. Good programmers use descriptive names. I just spent a day tracking down a real-time bug due to me calling a function outside a critical section.

How would you name a function to indicate that it should only be called from within a critical section? Something like doStuff_critical() with the "_critical" telling you the requirement for a critical section. But of course less ugly.

Any ideas?

Idea: Pthreads uses names like fputc_unlocked() for a similar
purpose, and you might imitate that. I don't think the ugliness
of such names should be much of a barrier; you *want* them to jump
out and be difficult to overlook -- even difficult to type, if the
functions should only be called in unusual circumstances.

But could you do better by reorganizing the program a bit?
By that I mean: In many cases, an "uncritical" piece of the program
calls a function that "goes critical" (acquires a lock, whatever),
does its job, restores normal mode, and returns to the caller, with
its work done and no longer "critical." If the function's work is
complex enough to be broken down into sub-functions, consider making
those subordinate functions `static' so outsiders cannot call them
directly but can only get at them through the "safe" API.

 

[Andrew Cooper]

Good programmers know about critical sections, which protect shared resources. Good programmers use descriptive names. I just spent a day tracking down a real-time bug due to me calling a function outside a critical section.

How would you name a function to indicate that it should only be called from within a critical section? Something like doStuff_critical() with the "_critical" telling you the requirement for a critical section. But of course less ugly.

Any ideas?

By and large, Linux and Xen tend to use foo() and __foo(), where __foo()
is the actual implementation, with assumptions about locks etc in the
comments, and foo() is a wrapper which takes the correct lock(s), irq
states etc.

As a result, non-critical sections can call foo() and bar(), while a
larger complicated critical section can take the relevant locks and call
the required __foo() and __bar() functions.

(Although it should be noted that kernel critical sections will probably
differ widely from application level critical sections)

~Andrew

 

[Keith Thompson]

By and large, Linux and Xen tend to use foo() and __foo(), where __foo()
is the actual implementation, with assumptions about locks etc in the
comments, and foo() is a wrapper which takes the correct lock(s), irq
states etc.

As a result, non-critical sections can call foo() and bar(), while a
larger complicated critical section can take the relevant locks and call
the required __foo() and __bar() functions.

(Although it should be noted that kernel critical sections will probably
differ widely from application level critical sections)

Identifiers starting with two underscores, or with an underscore and an
uppercase letter, are reserved to the implementation; if you define such
an identifer yourself, the behavior is undefined.

(The kernel is arguably part of the implementation, and even if it
isn't, it's probably ok for the developers to rely on certain behaviors
that aren't defined by the language standard.)

 

[Keith Thompson]

Good programmers know about critical sections, which protect shared
resources. Good programmers use descriptive names. I just spent a day
tracking down a real-time bug due to me calling a function outside a
critical section.

How would you name a function to indicate that it should only be
called from within a critical section? Something like
doStuff_critical() with the "_critical" telling you the requirement
for a critical section. But of course less ugly.

Any ideas?

zephodBeebleBrox_function

How does appending "_function" to the name suggest critical sections? Or
did you mean something else?

 

[Andrew Cooper]

Identifiers starting with two underscores, or with an underscore and an
uppercase letter, are reserved to the implementation; if you define such
an identifer yourself, the behavior is undefined.

(The kernel is arguably part of the implementation, and even if it
isn't, it's probably ok for the developers to rely on certain behaviors
that aren't defined by the language standard.)

I doubt anyone could make a functional kernel while strictly adhering to
non UD behaviour. There is "what the standard states" and "what
basically universally works".

Having said that, because of narrow architecture targets of kernels, you
can perhaps rely substantially more on "what will work" while strictly
being UD.

~Andrew (who had never really pondered this before)

 

[Eric Sosman]

[...]
Identifiers starting with two underscores, or with an underscore and an
uppercase letter, are reserved to the implementation; if you define such
an identifer yourself, the behavior is undefined.

(The kernel is arguably part of the implementation, and even if it
isn't, it's probably ok for the developers to rely on certain behaviors
that aren't defined by the language standard.)

I doubt anyone could make a functional kernel while strictly adhering to
non UD behaviour. There is "what the standard states" and "what
basically universally works".

If you hadn't said "universally" I'd have agreed with you,
more or less. But it is *not* universally true that you're
free to start your identifiers with __ and have things "work."
Even if you can get away with the particular set of __xxx you
use today with the particular compiler and options you use today,
you may find yourself in trouble tomorrow when you upgrade to the
next compiler version or invent a new identifier or even #include
a new header.

Example: Try this in gcc:

#include <stdio.h>
static const char *whom(void) {
return "World";
}
int main(void) {
printf("Hello, %s!\n", whom());
}

Everything working? Okay, now change the identifier `whom' to
`__attribute__'.

Having said that, because of narrow architecture targets of kernels, you
can perhaps rely substantially more on "what will work" while strictly
being UD.

Agreed that you can -- indeed, must -- rely on a lot of things
the C language itself does not guarantee. But adopting a dubious
naming convention (when there are plenty of others available) is
begging for trouble just for the thrill of begging.

 

[Tim Rentsch]

By and large, Linux and Xen tend to use foo() and __foo(), where __foo()
is the actual implementation, [snip]

Identifiers starting with two underscores, or with an underscore and an
uppercase letter, are reserved to the implementation; if you define such
an identifer yourself, the behavior is undefined.

(The kernel is arguably part of the implementation, and even if it
isn't, it's probably ok for the developers to rely on certain behaviors
that aren't defined by the language standard.)

The Linux kernel is part of no existing C implementation. And,
even if it were, it is not part of implementations running on
other operating systems (eg MS windows or MacOS), yet presumably
it's expected to be compileable some such environments, so it's
still breaking the rules regarding reserved identifiers.

Don't get me wrong, it's no big deal that these particular
rules are being broken in this case, but that doesn't mean
the rules aren't being broken.

 

[Stephen Sprunk]

The Linux kernel is part of no existing C implementation.

The _running_ kernel is arguably part of the implementation; the kernel
_source being compiled_ is not.

And, even if it were, it is not part of implementations running on other
operating systems (eg MS windows or MacOS), yet presumably it's expected
to be compileable some such environments, so it's still breaking the
rules regarding reserved identifiers.

The Linux kernel is only expected to be compilable by GCC, and successfully
compiling the Linux kernel is a gate in the GCC release process, so the two
are intimately tied together.

I would expect the same of Windows and MSVC, etc. Kernels are special.

Don't get me wrong, it's no big deal that these particular rules are
being broken in this case, but that doesn't mean the rules aren't being
broken.

In such a case, the normal rules are simply not relevant.

OTOH, that also means that one should always be careful before using kernel
source as an example of how to write non-kernel source.

S

 

[Tim Rentsch]

The _running_ kernel is arguably part of the implementation;

You mean it's arguably part of _an_ implementation. I will
take up this question further on.

the kernel _source being compiled_ is not.


The Linux kernel is only expected to be compilable by GCC,

Doesn't change my point, since GCC runs on systems besides
Linux.

and successfully compiling the Linux kernel is a gate in the
GCC release process, so the two are intimately tied together.

That doesn't make Linux part of a gcc implementation, any more
than a requirement for a successful compilation of 'rogue' would
make 'rogue' part of gcc implementations.

I would expect the same of Windows and MSVC, etc. Kernels are
special.

Kernels generally are more dependent on their compilation
environment than other programs. From a compiler's point
of view though they are still just programs.

In such a case, the normal rules are simply not relevant.

The rules are relevant precisely because the kernel must
ensure that the rules it chooses to violate won't be
messed up by any implementation-reserved decisions made
by the compiler in question. If the kernel didn't break
any rules, then it wouldn't matter which compiler is
used to compile it; it's because the kernel _does_ break
rules that it needs to be choosy about which compilers
it uses. What I think you mean is that, because the
kernel is compiled with a compiler that doesn't exhibit
destructive interference over the rules the kernel does
break, breaking those rules does not have any negative
effects; and certainly that is true (by definition
it would have to be).

OTOH, that also means that one should always be careful before
using kernel source as an example of how to write non-kernel
source.

I agree with that, but I think that's more an artifact of
expecting certain definitions of implementation-defined and
implementation-dependent behavior than it is of being a kernel.
Kernels are more prone to rely on those things than most
programs; but so also are many or most programs that run
on bare hardware, and certainly not all of those are kernels.

On the earlier question of whether Linux (or any typical modern
operating system) is part of a C implementations --

Paragraph 1 of section 5 says

An implementation translates C source files and executes C
programs in two data-processing-system environments, which
will be called the /translation environment/ and the
/execution environment/ in this International Standard.

Paragraph 2 of section 1 says

This International Standard does not specify

[...other items...]

. all minimal requirements of a data-processing system that
is capable of supporting a conforming implementation.

My argument is that a running Linux kernel supplies an execution
environment (and perhaps also a translation environment), which
under the descriptions in sections 1 and 5 is a data-processing
system, and as such these /support/ conforming implementations but
are not themselves /part of/ conforming implementations. The
Standard draws a distinct boundary between the two; and conventional
operating systems are clearly on the non-implementation side of that
boundary.

 

[Ian Collins]

The _running_ kernel is arguably part of the implementation; the kernel
_source being compiled_ is not.


The Linux kernel is only expected to be compilable by GCC, and successfully
compiling the Linux kernel is a gate in the GCC release process, so the two
are intimately tied together.

I would expect the same of Windows and MSVC, etc. Kernels are special.

Not necessarily. One of the early tasks when the Solaris kernel was
open-sourced was to get it to compile cleanly with gcc as well as the
native compiler. This took a while, but in the process removed a lot of
cruft from the source. Just like any other code base, being able to
compile with more than one compiler is a good way to improve and
maintain code quality. From my occasional exposure to it, my impression
is the Linux kernel is a lost cause when it comes to compiler portability!

Due to their size and reliance on high levels of optimisation, kernels
are more susceptible than most applications to compiler bugs. This
should be seen as an opportunity to improve compiler quality rather than
a direct coupling.

In such a case, the normal rules are simply not relevant.

OTOH, that also means that one should always be careful before using kernel
source as an example of how to write non-kernel source.

See above.

 

[Stephen Sprunk]

You mean it's arguably part of _an_ implementation. I will take up
this question further on.

I was assuming the context of compiling the Linux kernel on a running
Linux system. Obviously, if you're compiling the Linux kernel with a
cross-compiler running on some other OS, then the Linux kernel would not
be part of the implementation.

My point was that it's not the kernel source that was being claimed to
be part of the implementation.

Doesn't change my point, since GCC runs on systems besides Linux.

True, except that it undercuts the justification for your point. If the
Linux kernel is only expected to be compilable by GCC, then it is free
to take advantage of GCC's implementation-defined behavior--and that is
exactly what started this discussion.

That doesn't make Linux part of a gcc implementation, any more than a
requirement for a successful compilation of 'rogue' would make
'rogue' part of gcc implementations.


Kernels generally are more dependent on their compilation environment
than other programs. From a compiler's point of view though they are
still just programs.

That depends. When GCC has flags (eg. -cmodel=kernel) to tell the
compiler to use a special mode only for kernels, that seems to imply
kernels are not "just programs."

Also, a few years ago GCC added an optimization that _only_ broke
kernels: it removed null pointer checks after a pointer had been
dereferenced on the assumption that if the pointer had been null,
execution could not have continued. That assumption does not hold in
kernel mode, though, which resulted in a security vulnerability in the
Linux kernel. Kernels _are_ different in practice, not just theory.

The rules are relevant precisely because the kernel must ensure that
the rules it chooses to violate won't be messed up by any
implementation-reserved decisions made by the compiler in question.

.... unless the implementation has made an explicit statement that it
will not violate any assumptions the kernel makes, as in the case of GCC
with respect to the Linux kernel. (Including, for instance, the
assumption that dereferencing a null pointer has well-defined behavior.)

Note that this does _not_ apply to other kernels that may be compiled
with GCC, in which case your point would be valid.

If the kernel didn't break any rules, then it wouldn't matter which
compiler is used to compile it; it's because the kernel _does_
break rules that it needs to be choosy about which compilers it uses.

True, but nobody seems to care about that.

Well, Intel seems to have cared, to the point that being able to compile
the Linux kernel was considered a "must have" for ICC to be viable in
the Linux market. That wouldn't have been such a big deal if the kernel
didn't take advantage of--or dictate--GCC's peculiarities.

What I think you mean is that, because the kernel is compiled with a
compiler that doesn't exhibit destructive interference over the rules
the kernel does break, breaking those rules does not have any
negative effects; and certainly that is true (by definition it would
have to be).

I'm not sure what you mean here.

I agree with that, but I think that's more an artifact of expecting
certain definitions of implementation-defined and
implementation-dependent behavior than it is of being a kernel.
Kernels are more prone to rely on those things than most programs;
but so also are many or most programs that run on bare hardware, and
certainly not all of those are kernels.

That leads to debating what we're really referring to by the term
"kernel", since I doubt we're really restricting it to just OS kernels
but rather any software that runs directly on the hardware without any
intermediary.

My argument is that a running Linux kernel supplies an execution
environment (and perhaps also a translation environment), which under
the descriptions in sections 1 and 5 is a data-processing system, and
as such these /support/ conforming implementations but are not
themselves /part of/ conforming implementations.

Fair enough.

S

 

[Stephen Sprunk]

And, even if [the kernel] were [part of the implementation], it
is not part of implementations running on other operating systems
(eg MS windows or MacOS), yet presumably it's expected to be
compileable some such environments, so it's still breaking the
rules regarding reserved identifiers.

The Linux kernel is only expected to be compilable by GCC, and
successfully compiling the Linux kernel is a gate in the GCC
release process, so the two are intimately tied together.

I would expect the same of Windows and MSVC, etc. Kernels are
special.

Not necessarily. One of the early tasks when the Solaris kernel was
open-sourced was to get it to compile cleanly with gcc as well as the
native compiler. This took a while, but in the process removed a lot
of cruft from the source. Just like any other code base, being able
to compile with more than one compiler is a good way to improve and
maintain code quality.

I agree that making code portable tends to increase quality, but that's
not really the point.

From my occasional exposure to it, my impression is the Linux kernel
is a lost cause when it comes to compiler portability!

Probably. I'll note that the ICC folks chose to copy GCC's "features"
rather than change the Linux kernel source itself to be more portable.
I don't know what drove that decision, nor am I qualified to judge
whether the kernel developers are justified in the use of said
"features" in the first place, since they're obviously more skilled than
I am.

Due to their size and reliance on high levels of optimisation,
kernels are more susceptible than most applications to compiler
bugs.

I don't think it's bugs per se but that kernels, by their nature, tend
to rely on behaviors that the Standard does not (and cannot) guarantee,
which means they become tied to the particular compiler(s) used to
compile them.

IMHO, the ability to write both portable and non-portable code in the
same language is one of C's strengths--and a reason for its enduring
success. However, it takes discipline to segregate the two types of
code, which apparently many people (including those who write books)
seem to be lacking.

S

 

[Tim Rentsch]

I was assuming the context of compiling the Linux kernel on a running
Linux system. Obviously, if you're compiling the Linux kernel with a
cross-compiler running on some other OS, then the Linux kernel would not
be part of the implementation.

My point was that it's not the kernel source that was being claimed to
be part of the implementation.


True, except that it undercuts the justification for your point. If the
Linux kernel is only expected to be compilable by GCC, then it is free
to take advantage of GCC's implementation-defined behavior--and that is
exactly what started this discussion.


That depends. When GCC has flags (eg. -cmodel=kernel) to tell the
compiler to use a special mode only for kernels, that seems to imply
kernels are not "just programs."

Also, a few years ago GCC added an optimization that _only_ broke
kernels: it removed null pointer checks after a pointer had been
dereferenced on the assumption that if the pointer had been null,
execution could not have continued. That assumption does not hold in
kernel mode, though, which resulted in a security vulnerability in the
Linux kernel. Kernels _are_ different in practice, not just theory.


... unless the implementation has made an explicit statement that it
will not violate any assumptions the kernel makes, as in the case of GCC
with respect to the Linux kernel. (Including, for instance, the
assumption that dereferencing a null pointer has well-defined behavior.)

Note that this does _not_ apply to other kernels that may be compiled
with GCC, in which case your point would be valid.


True, but nobody seems to care about that.

Well, Intel seems to have cared, to the point that being able to compile
the Linux kernel was considered a "must have" for ICC to be viable in
the Linux market. That wouldn't have been such a big deal if the kernel
didn't take advantage of--or dictate--GCC's peculiarities.


I'm not sure what you mean here.


That leads to debating what we're really referring to by the term
"kernel", since I doubt we're really restricting it to just OS kernels
but rather any software that runs directly on the hardware without any
intermediary.


Fair enough.

Rather than trying to respond point-by-point, let me summarize.

What I think you're saying is that, for all practical purposes,
gcc is effectively part of the Linux kernel; the Linux kernel
depends so much on gcc for its compilation that the kernel
as a runnable entity basically doesn't exist without gcc.

What I'm trying to say is that, even granting that gcc is part
of the Linux kernel, the Linux kernel is not part of any gcc
implementation. And I think you agreed to that right at the
end there.

As long as you agree with those last two paragraphs, I think
we're all good.