Searched hist:252212 (Results 1 - 4 of 4) sorted by relevance
/freebsd-10.2-release/sys/kern/ | ||
H A D | kern_rwlock.c | diff 252212 Tue Jun 25 20:29:25 MDT 2013 jhb A few mostly cosmetic nits to aid in debugging: - Call lock_init() first before setting any lock_object fields in lock init routines. This way if the machine panics due to a duplicate init the lock's original state is preserved. - Somewhat similarly, don't decrement td_locks and td_slocks until after an unlock operation has completed successfully. |
H A D | kern_sx.c | diff 252212 Tue Jun 25 20:29:25 MDT 2013 jhb A few mostly cosmetic nits to aid in debugging: - Call lock_init() first before setting any lock_object fields in lock init routines. This way if the machine panics due to a duplicate init the lock's original state is preserved. - Somewhat similarly, don't decrement td_locks and td_slocks until after an unlock operation has completed successfully. |
H A D | kern_lock.c | diff 252212 Tue Jun 25 20:29:25 MDT 2013 jhb A few mostly cosmetic nits to aid in debugging: - Call lock_init() first before setting any lock_object fields in lock init routines. This way if the machine panics due to a duplicate init the lock's original state is preserved. - Somewhat similarly, don't decrement td_locks and td_slocks until after an unlock operation has completed successfully. |
H A D | kern_mutex.c | diff 252212 Tue Jun 25 20:29:25 MDT 2013 jhb A few mostly cosmetic nits to aid in debugging: - Call lock_init() first before setting any lock_object fields in lock init routines. This way if the machine panics due to a duplicate init the lock's original state is preserved. - Somewhat similarly, don't decrement td_locks and td_slocks until after an unlock operation has completed successfully. |
Completed in 140 milliseconds