Date: Thu, 15 May 2008 09:24:56 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-stable@freebsd.org, David Xu <davidxu@freebsd.org>, Brent Casavant <b.j.casavant@ieee.org>, freebsd-threads@freebsd.org Subject: Re: thread scheduling at mutex unlock Message-ID: <Pine.GSO.4.64.0805150916400.28524@sea.ntplx.net> In-Reply-To: <482BF5EA.5010806@icyb.net.ua> References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org> <482BF5EA.5010806@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 15 May 2008, Andriy Gapon wrote:
> Or even more realistic: there should be a feeder thread that puts things on
> the queue, it would never be able to enqueue new items until the queue
> becomes empty if worker thread's code looks like the following:
>
> while(1)
> {
> pthread_mutex_lock(&work_mutex);
> while(queue.is_empty())
> pthread_cond_wait(...);
> //dequeue item
> ...
> pthread_mutex_unlock(&work mutex);
> //perform some short and non-blocking processing of the item
> ...
> }
>
> Because the worker thread (while the queue is not empty) would never enter
> cond_wait and would always re-lock the mutex shortly after unlocking it.
Well in theory, the kernel scheduler will let both threads run fairly
with regards to their cpu usage, so this should even out the enqueueing
and dequeueing threads.
You could also optimize the above a little bit by dequeueing everything
in the queue instead of one at a time.
> So while improving performance on small scale this mutex re-acquire-ing
> unfairness may be hurting interactivity and thread concurrency and thus
> performance in general. E.g. in the above example queue would always be
> effectively of depth 1.
> Something about "lock starvation" comes to mind.
>
> So, yes, this is not about standards, this is about reasonable expectations
> about thread concurrency behavior in a particular implementation (libthr).
> I see now that performance advantage of libthr over libkse came with a price.
> I think that something like queued locks is needed. They would clearly reduce
> raw throughput performance, so maybe that should be a new (non-portable?)
> mutex attribute.
--
DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0805150916400.28524>