|
Home > Archive > Unix Programming > October 2006 > signal and atomic condition
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
signal and atomic condition
|
|
|
| Hello,
Just a little question about atomic condition.
The starting : A main program which is incrementing, in an endless
loop, a shared integer variable.
Great 
Now imagine that to add +1 to the shared variable, the CPU must "use"
10 opcodes and then after having executed the first 5 opcodes, a signal
(that I have define/caught previously) occurs...
What will be the value of my shared variable in my signal-handler
function ?
Other doubt :
Before leaving the same signal-handler function, I change my shared
variable into an other value,
Now I go back to the main loop, and now the big mess :
Remember : the CPU have to achieve the last 5 opcodes to change the
value of the shared variable,
but its initial value is'nt the same anymore (changed in the
signal-handler function)
I know this kind of behavior could happens with thread, but is is also
true for signal ?
thanx for your answers...
steph
| |
| David Schwartz 2006-09-29, 7:57 pm |
|
stef wrote:
> Hello,
>
> Just a little question about atomic condition.
>
> The starting : A main program which is incrementing, in an endless
> loop, a shared integer variable.
>
> Great
>
> Now imagine that to add +1 to the shared variable, the CPU must "use"
> 10 opcodes and then after having executed the first 5 opcodes, a signal
> (that I have define/caught previously) occurs...
> What will be the value of my shared variable in my signal-handler
> function ?
It is undefined behavior. The program could even crash. The C standard
clearly specifies how to allow access to a varible in a signal handler,
and if you break the rules, anything could happen.
> Other doubt :
> Before leaving the same signal-handler function, I change my shared
> variable into an other value,
> Now I go back to the main loop, and now the big mess :
> Remember : the CPU have to achieve the last 5 opcodes to change the
> value of the shared variable,
> but its initial value is'nt the same anymore (changed in the
> signal-handler function)
Right, that's why you're not allowed to do that.
> I know this kind of behavior could happens with thread, but is is also
> true for signal ?
Yes, follow the rules. See, for example:
http://www.cs.utah.edu/dept/old/tex..._21.html#SEC358
What you can do in a signal handler that is invoked asynchronously is
quite limited.
DS
| |
| Rainer Weikusat 2006-10-01, 7:26 pm |
| "David Schwartz" <davids@webmaster.com> writes:
[...]
> It is undefined behavior. The program could even crash. The C standard
> clearly specifies how to allow access to a varible in a signal handler,
> and if you break the rules, anything could happen.
The C standard states that the behaviour is undefined if a signal
handler accesses an object with static storage duration that is not
declared as 'volatile sig_atomic_t'. UNIX(*) (SUS) just say that
sig_atomic_t is a 'possibly volatile-qualified type', which can be
accessed atomically even in the presence of asynchronous interrupts.
Additionally, SUS defines a fairly large set of functions that are
supposed to be async-signal safe, while C only allows calls to abort,
_Exit and to signal, insofar it is used for a 'tradtional' signal
handler restablishment.
Regarding the 'undefined means random' myth: According to the
C-standard, undefined means 'no requirements are imposed'. This, in
turn, means, that whatever behaviour an actual implementation may
exhibit when confronted with 'undefinedness' is not relevant for
determining if this implementation conforms to the standard.
|
|
|
|
|