Updated rusage patch

Jeff Roberson jroberson at chesapeake.net
Fri Jun 1 09:57:27 UTC 2007


On Fri, 1 Jun 2007, Bruce Evans wrote:

> On Thu, 31 May 2007, Jeff Roberson wrote:
>
>> Now that I've said all of that and committed the patch, I just realized 
>> that there is still one race that is unacceptable.  When the thread exits 
>> in thread_exit() and adds the stats of both threads together we could lose 
>> changes in the still-running thread.
>
> I think I see.
>
> The same problem seems to affect all calls to ruxagg() and rucollect()
> for threads that aren't curthread.  You cannot control the stats for
> other threads using a spinlock since statclock() doesn't use a spinlock
> for the tick counts and shouldn't (modulo this bug) use one for the
> rss's.  Resetting the tick counts in ruxagg() is particulary dangerous.
> Resetting the runtime in ruxagg() isn't a problem because the runtime
> isn't touched by statclock().  ruxcollect() only does insufficently
> locked accesses for reading the rss's, except in thread_exit().  It
> should be easy to avoid the resettings by accumulating into a local
> rux as is already done for ru's (put an rux in each thread and add
> these up when required).  This reduces to the same problem as for the
> rss's.

Well, it isn't terribly inconvenient to hold the sched_lock/thread_lock in 
statclock() where the stats are updated.  This makes the solution simply 
to grab thread/sched lock in ruxagg().

Jeff

>
> Bruce
>


More information about the freebsd-arch mailing list