[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 07/12] qemu-thread: add QemuSemaphore

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 07/12] qemu-thread: add QemuSemaphore
Date: Mon, 16 Jul 2012 15:20:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

Il 16/07/2012 14:00, Jan Kiszka ha scritto:
> On 2012-07-16 12:42, Paolo Bonzini wrote:
>> The new thread pool will use semaphores instead of condition
>> variables, because QemuCond does not have qemu_cond_timedwait.
> I'll post an updated patch (according to last round's review comments)
> that adds this service for POSIX. I bet you'll find a way to extend it
> to Win32 if that is required. ;)

I can do that (or just use pthreads-win32), but only at the cost of
making cond_wait() slower and more complex.

>> (I also like it more this way, since semaphores model well the
>> producer-consumer problem).
> Let's not introduce another synchronization mechanism unless there is a
> real need. Semaphores tend to be misused for things they don't fit, so
> better keep them out of reach.

That's what patch review is for...

> Also, if you do producer-consumer this way, you need a down() for every
> entity you dequeue. In contrast, you only interact with condition
> variables if there the consumer queue is empty - less atomic ops.

It doesn't really matter.  You want the thread pool to service requests
as fast as possible, which means you'll have always at least one free
thread waiting on the semaphore or cv.  So, with either semaphores or
cvs, the slow path is actually the normal case.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]