«

hi, is fork runs faster then thread in java?
thanks
from Peter ()

In article <15cf029d-e8bc-47de-8b83->,
Peter Cheung <> wrote:

> [Does] fork run faster then thread in Java?

It appears to depend on the granularity. This article cites Doug Lea's
paper on the subject:

<http://www.drdobbs.com/jvm/using-jdk-7s-forkjoin-framework/231000556>

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

On 8/26/2012 2:40 AM, Peter Cheung wrote:
> hi, is fork runs faster then thread in java?

I don't understand the question.

The fork join framework does use threads.

It just provides an easy programming model
for writing multithreaded code.

Arne

On Sat, 25 Aug 2012 23:40:38 -0700 (PDT), Peter Cheung
<> wrote, quoted or indirectly quoted someone who said
:

>hi, is fork runs faster then thread in java?

There is obviously less overhead with a new thread than forking off a
new process. A thread shares the same pool of objects. A fork has
its own JVM and pool of objects. Forking is usually to code you had
nothing to do with writing or that is written in other languages.
Threads are when the piece of work to do is quite small or needs
access to your object pool.
--
Roedy Green Canadian Mind Products http://mindprod.com
A new scientific truth does not triumph by convincing its opponents and making them see the light,
but rather because its opponents eventually die, and a new generation grows up that is familiar with it.
~ Max Planck 1858-04-23 1947-10-04

Roedy Green wrote:
> Peter Cheung wrote, quoted or indirectly quoted someone who said:
>>hi, is fork runs faster then thread in java?
>

> There is obviously less overhead with a new thread than forking off a
> new process. A thread shares the same pool of objects. A fork has

What does that have to do with Java?

In Java the exact opposite is true:
http://docs.oracle.com/javase/7/docs...kJoinTask.html
"
Abstract base class for tasks that run within a ForkJoinPool. A ForkJoinTask is a thread-like entity that is much lighter weight than a normal thread.Huge numbers of tasks and subtasks may be hosted by a small number of actual threads in a ForkJoinPool, at the price of some usage limitations."

> its own JVM and pool of objects. Forking is usually to code you had
> nothing to do with writing or that is written in other languages.

Unless, of course, you are talking about forking in the Java sense.

> Threads are when the piece of work to do is quite small

No, that's not true at all.

Threads are just fine when the piece of work is large, and in many cases
are motivated by the need to do large pieces of work. The whole idea of
'SwingWorker', for example, is to perform large units of work in a different
thread from the GUI.

> or needs access to your object pool.

That is true, assuming you need concurrency.

Well, partially true. In many cases there are non-thread solutions.

--
Lew

On 8/28/2012 3:54 PM, Lew wrote:
> Roedy Green wrote:
>> Peter Cheung wrote, quoted or indirectly quoted someone who said:
>>> hi, is fork runs faster then thread in java?
>>
>
>> There is obviously less overhead with a new thread than forking off a
>> new process. A thread shares the same pool of objects. A fork has
>
> What does that have to do with Java?

Traditionally, the term "fork" has been used to refer to "creating a new
process" (the traditional way of handling concurrency in Unix code)--the
Unix syscall for this step is literally called "fork." On Unix-based
system, process creation is extremely low overhead, so process-based
parallelism was more common than on Windows where making a new process
is painfully slow.

When I first saw the OP's question, I first thought he was referring to
fork in the process-creation sense, so it's not clear to me offhand if
he is referring to the process-creation fork or Java-framework fork.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Joshua Cranmer wrote:
> Lew wrote:
>> Roedy Green wrote:
>>> Peter Cheung wrote, quoted or indirectly quoted someone who said:
>>>> hi, is fork runs faster then thread in java [sic]?
>
>>> There is obviously less overhead with a new thread than forking off a
>>> new process. A thread shares the same pool of objects. A fork has
>
>> What does that have to do with Java?
>
> Traditionally, the term "fork" has been used to refer to "creating a new
> process" (the traditional way of handling concurrency in Unix code)--the
> Unix syscall for this step is literally called "fork." On Unix-based
> system, process creation is extremely low overhead, so process-based
> parallelism was more common than on Windows where making a new process
> is painfully slow.
>
> When I first saw the OP's question, I first thought he was referring to
> fork in the process-creation sense, so it's not clear to me offhand if
> he is referring to the process-creation fork or Java-framework fork.

The OP explicitly said, "in java [sic]". That clears up that question completely.

--
Lew

On 8/28/2012 7:48 PM, Lew wrote:
> Joshua Cranmer wrote:
>> When I first saw the OP's question, I first thought he was referring to
>> fork in the process-creation sense, so it's not clear to me offhand if
>> he is referring to the process-creation fork or Java-framework fork.
>
> The OP explicitly said, "in java [sic]". That clears up that question completely.

Not necessarily. If he meant the Java framework, I would have expected
him to refer to it as "fork-join" instead of as just plain "fork".
People do ask questions in this newsgroup all the time without naming
things reliably.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

Joshua Cranmer wrote:
> Lew wrote:
>> The OP explicitly said, "in java [sic]". That clears up that question completely.
>
> Not necessarily. If he meant the Java framework, I would have expected
> him to refer to it as "fork-join" instead of as just plain "fork".
> People do ask questions in this newsgroup all the time without naming
> things reliably.

You raise a good point.

I suppose I put too much faith in the wording.

--
Lew