Searched hist:"98 c926b20fcc0953abe69be05b43e9cfc95b2c47" (Results 1 – 2 of 2) sorted by relevance
/freebsd/sys/sys/ |
H A D | callout.h | diff 98c926b20fcc0953abe69be05b43e9cfc95b2c47 Mon Feb 07 03:47:33 CET 2005 Ian Dowse <iedowse@FreeBSD.org> Add a mechanism for associating a mutex with a callout when the callout is first initialised, using a new function callout_init_mtx(). The callout system will acquire this mutex before calling the callout function and release it on return.
In addition, the callout system uses the mutex to avoid most of the complications and race conditions inherent in asynchronous timer facilities, so mutex-protected callouts have much simpler semantics. As long as the mutex is held when invoking callout_stop() or callout_reset(), then these functions will guarantee that the callout will be stopped, even if softclock() had already begun to process the callout.
Existing Giant-locked callouts will automatically pick up the new race-free semantics. This should close a number of race conditions in the USB code and probably other areas of the kernel too.
There should be no change in behaviour for "MP-safe" callouts; these still need to use the techniques mentioned in timeout(9) to avoid race conditions. diff 98c926b20fcc0953abe69be05b43e9cfc95b2c47 Mon Feb 07 03:47:33 CET 2005 Ian Dowse <iedowse@FreeBSD.org> Add a mechanism for associating a mutex with a callout when the callout is first initialised, using a new function callout_init_mtx(). The callout system will acquire this mutex before calling the callout function and release it on return.
In addition, the callout system uses the mutex to avoid most of the complications and race conditions inherent in asynchronous timer facilities, so mutex-protected callouts have much simpler semantics. As long as the mutex is held when invoking callout_stop() or callout_reset(), then these functions will guarantee that the callout will be stopped, even if softclock() had already begun to process the callout.
Existing Giant-locked callouts will automatically pick up the new race-free semantics. This should close a number of race conditions in the USB code and probably other areas of the kernel too.
There should be no change in behaviour for "MP-safe" callouts; these still need to use the techniques mentioned in timeout(9) to avoid race conditions.
|
/freebsd/sys/kern/ |
H A D | kern_timeout.c | diff 98c926b20fcc0953abe69be05b43e9cfc95b2c47 Mon Feb 07 03:47:33 CET 2005 Ian Dowse <iedowse@FreeBSD.org> Add a mechanism for associating a mutex with a callout when the callout is first initialised, using a new function callout_init_mtx(). The callout system will acquire this mutex before calling the callout function and release it on return.
In addition, the callout system uses the mutex to avoid most of the complications and race conditions inherent in asynchronous timer facilities, so mutex-protected callouts have much simpler semantics. As long as the mutex is held when invoking callout_stop() or callout_reset(), then these functions will guarantee that the callout will be stopped, even if softclock() had already begun to process the callout.
Existing Giant-locked callouts will automatically pick up the new race-free semantics. This should close a number of race conditions in the USB code and probably other areas of the kernel too.
There should be no change in behaviour for "MP-safe" callouts; these still need to use the techniques mentioned in timeout(9) to avoid race conditions. diff 98c926b20fcc0953abe69be05b43e9cfc95b2c47 Mon Feb 07 03:47:33 CET 2005 Ian Dowse <iedowse@FreeBSD.org> Add a mechanism for associating a mutex with a callout when the callout is first initialised, using a new function callout_init_mtx(). The callout system will acquire this mutex before calling the callout function and release it on return.
In addition, the callout system uses the mutex to avoid most of the complications and race conditions inherent in asynchronous timer facilities, so mutex-protected callouts have much simpler semantics. As long as the mutex is held when invoking callout_stop() or callout_reset(), then these functions will guarantee that the callout will be stopped, even if softclock() had already begun to process the callout.
Existing Giant-locked callouts will automatically pick up the new race-free semantics. This should close a number of race conditions in the USB code and probably other areas of the kernel too.
There should be no change in behaviour for "MP-safe" callouts; these still need to use the techniques mentioned in timeout(9) to avoid race conditions.
|