[concurrency-interest] Subject: Re: Latency in starting threads

David Dice david.dice at gmail.com
Tue Apr 16 23:10:54 EDT 2013


Message: 6
> Date: Wed, 17 Apr 2013 10:18:45 +1000
> From: "David Holmes" <davidcholmes at aapt.net.au>
> To: "Dr Heinz M. Kabutz" <heinz at javaspecialists.eu>
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Latency in starting threads
> Message-ID: <NFBBKALFDCPFIDBNKAPCAECDJMAA.davidcholmes at aapt.net.au>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Heinz,
>
> It is perfected valid for t.start() to start and context switch to the new
> thread. That is up to the OS scheduler.
>
> Thread.join only indicates logical termination at the Java level. The
> native
> thread will still have to exit at the VM level and OS level, both of which
> can hit bottlenecks and cause unexpected numbers of threads to still be
> active. That in turn can impact thread creation - which happens in start().
>
> Cheers,
> David
>
>
Following up on what David said, it's not uncommon to have the launching
thread preempted by the launchee.

IIRC, on linux it was a good idea to implement fork() such that the spawned
thread would preempt the parent, as there was a good chance the child was
going to exec() anyway, and preempting the parent would cut down on COW
faults and address-space cleaving.  I think the thread subsystem still
borrows a good deal of plumbing and policy from fork(), possibly explaining
the policy on linux.   It's possible the same might apply to MacOS.

Waker preemption by the wakee is also common.   It's a good idea that
notify/notifyAll don't actually wake any thread in the critical section --
we really don't want preemption at that point.   In HotSpot
notify/notifyAll simply move a thread from the waitset to the list of
threads contending for the lock.   At worst we'll wake a notifyee after
having dropped the lock.

The host OS scheduler manages all transitions between 'ready' and 'running'
states, so we're typically at its mercy.

Regards
Dave

https://blogs.oracle.com/dave/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130416/91ee57f3/attachment.html>


More information about the Concurrency-interest mailing list