[x264-devel] Updated (and hopefully final) threaded slicetype patch

[Måns Rullgård]

David DeHaven <dave at sagetv.com> writes:

>>>>
>>>> I said these should be replaced with cond_wait, but this made the
>>>> patch much much slower, which makes me suspect it's waiting when it
>>>> shouldn't; the overhead of pthreads should be minimal.
>>>
>>> What about pthread conditions is minimal? In some cases (e.g. Mac OS
>>> X) you're forcing a context switch into the kernel to perform the
>>> signaling. Also, when you give up processor time to another thread by
>>> blocking thread execution (rather than spinning) you're committing
>>> yourself to NOT get any CPU time at least for the next time slice
>>> duration which on a lot of systems can be pretty significant.
>>
>> Do any modern systems still have timeslices in the classical sense?
>
> Yes.
>
> Here's a decent article on the Linux 2.6 scheduler:
> http://www.ibm.com/developerworks/linux/library/l-scheduler/

That article is 3 years old.

> Notice one of the first thing he says: "An important goal of a
> scheduler is to allocate CPU time slices ..."

That is using the term very generically.  What I meant was that modern
operating systems (with the exception of certain real-time OSes) do
not have fixed-length time slices.  The highest-priority runnable
process gets to run, no matter how recently it last ran.  Linux
doesn't even have a constant tick rate.

-- 
Måns Rullgård
mans at mansr.com