signal handlers, volatile, sig_atomic_t, and correct behaviour
Christopher Friesen
Given that Linux gives only one real timer per process, I've written a class
that creates a linked list of timer events stored as offsets from each other.
The way it works is that the first element in the list is the one for which the
timer is actually running, and each element stores a time offset from the
previous one.
The tricky bit comes in when you can manually add/remove/query entries in the
list, but at the same time the timer may fire for the first element in the list,
thus modifying any number of list elements. What I've done is something like
this:
//these are both initialized to zero in the constructor
volatile sig_atomic_t signal_fired, manipulating_list;
//this is set up to handle SIGALRM
void Timer::signal_handler(const int sig)
{
if (manipulating_list)
{
signal_fired = 1;
return;
}
else
{
//call methods on a staticly defined event list class to
//loop through all expired events to pull them off the event
//list, reschedule them if appropriate, and run an event handler.
//needless to say, this will change pointers around
return;
}
}
//this is an example of one of the other methods
int Timer::remove (int &timerNum)
{
manipulating_list = 1;
//remove the event from the timer queue
Event tempEvent = timerList.remove(timerNum);
manipulating_list = 0;
if (signal_fired)
timerSigHandler(SIGALRM);
if (tempEvent.isValid())
{
timerNum = 0;
return 0;
}
else
return -1;
}
Now, given this sort of arrangement, am I guaranteed that both routines will
always see consistant data in the linked list? If not, what do I need to do to
guarantee this? Is this an implementation-dependent thing? The standard seems
to say that I'm not allowed to do anything in the signal handler but set a
sig_atomic_t variable...obviously I could potentially do a lot more than that
here.
Thanks for your responses.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: cfri...@nortelnetworks.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Kaz Kylheku
>Now, given this sort of arrangement, am I guaranteed that both routines will
>always see consistant data in the linked list? If not, what do I need to do to
>guarantee this? Is this an implementation-dependent thing? The standard seems
>to say that I'm not allowed to do anything in the signal handler but set a
>sig_atomic_t variable...
Which means that if you want to do more things, it's not topical in
comp.lang.c++ or comp.std.c++.
>obviously I could potentially do a lot more than that
If you want to ensure mutual exclusion between a POSIX process and its
handler for an asynchronous signal, simply have the process block that
signal when manipulating the shared data. This is analogous to disabling
interrupts when manipulating data shared by an interrupt service routines.
ISO C and C++ do not define the existence of signal masks.
Neil Butterworth
news:3B6039E4...@nortelnetworks.com...
>
> Given that Linux gives only one real timer per process,
[snip]
And your Standard C++ (which has no concept of timers) question is?
Why not re-post this to somewhere like comp.os.linux..development.apps?
NeilB
t...@cs.ucr.edu
: The standard seems to say that I'm not allowed to do anything in the signal
: handler but set a sig_atomic_t variable...
Signal handlers get to set flags. That's about all.
: obviously I could potentially do a lot more than that here.
... but not within the realm of behavior that is defined by the C++
Standard. See comp.programming.threads for discussion of extensions
to the C/C++ standards (e.g., POSIX) that embrace asynchrony and
concurrency.
Tom Payne