* Questions regarding del_timer_sync() and re-registering timers
@ 2014-04-15 14:45 Jimmie Mayfield
0 siblings, 0 replies; only message in thread
From: Jimmie Mayfield @ 2014-04-15 14:45 UTC (permalink / raw)
To: kernelnewbies
Hi. The conventional wisdom when mixing del_timer_sync() with timers
that re-register themselves is that the caller must ensure that re-registration
does not happen.
>From kernel/timer.c:
* Synchronization rules: Callers must prevent restarting of the timer,
* otherwise this function is meaningless.
Now, the pseudo-code for del_timer_sync and try_to_del_timer_sync looks
something like this (ignoring the lock manipulation):
while (1) {
if (timer is not running) {
if timer is pending then detach it
break
}
else {
sleep
}
}
So that the loop continues to spin until the timer function is no longer
running at which point the kernel checks the pending list and removes it if
necessary.
Q: So given this construct, why is it imperative that the timer
function not re-register itself?
I could understand that restriction if the timer function might be running on
another CPU when the "if timer is pending then detach" step is executed but
it's not obvious to me how that's possible since base->lock is owned at
that point (not shown in the pseudocode)?
Can someone briefly point out what I've missed?
Jimmie
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2014-04-15 14:45 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-04-15 14:45 Questions regarding del_timer_sync() and re-registering timers Jimmie Mayfield
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).