Date: Thu, 15 May 2008 20:57:23 +0800 From: David Xu <davidxu@freebsd.org> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-stable@freebsd.org, Brent Casavant <b.j.casavant@ieee.org>, freebsd-threads@freebsd.org Subject: Re: thread scheduling at mutex unlock Message-ID: <482C3333.1070205@freebsd.org> In-Reply-To: <482C0206.1050206@icyb.net.ua> References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org> <482BF5EA.5010806@icyb.net.ua> <482BFCE3.7080704@freebsd.org> <482C0206.1050206@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Andriy Gapon wrote: > > Maybe. But that's not what I see with my small example program. One > thread releases and re-acquires a mutex 10 times in a row while the > other doesn't get it a single time. > I think that there is a very slim chance of a blocked thread > preempting a running thread in this circumstances. Especially if > execution time between unlock and re-lock is very small. It does not depends on how many times your thread acquires or re-acquires mutex, or how small the region the mutex is protecting. as long as current thread runs too long, other threads will have higher priorities and the ownership definitely will be transfered, though there will be some extra context switchings. > I'd rather prefer to have an option to have FIFO fairness in mutex > lock rather than always avoiding context switch at all costs and > depending on scheduler to eventually do priority magic. > It is better to implement this behavior in your application code, if it is implemented in thread library, you still can not control how many times acquiring and re-acquiring can be allowed for a thread without context switching, a simple FIFO as you said here will cause dreadful performance problem.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?482C3333.1070205>