Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #18317 > unrolled thread

thread vs fork?

Back to article view | Back to comp.lang.java.programmer

Contents

  thread vs fork? Peter Cheung <cmk128@gmail.com> - 2012-08-25 23:40 -0700
    Re: thread vs fork? "John B. Matthews" <nospam@nospam.invalid> - 2012-08-26 03:27 -0400
    Re: thread vs fork? Arne Vajhøj <arne@vajhoej.dk> - 2012-08-26 09:34 -0400
    Re: thread vs fork? Roedy Green <see_website@mindprod.com.invalid> - 2012-08-28 00:52 -0700
      Re: thread vs fork? Lew <lewbloch@gmail.com> - 2012-08-28 13:54 -0700
        Re: thread vs fork? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-08-28 19:08 -0500
          Re: thread vs fork? Lew <lewbloch@gmail.com> - 2012-08-28 17:48 -0700
            Re: thread vs fork? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-08-28 20:01 -0500
              Re: thread vs fork? Lew <lewbloch@gmail.com> - 2012-08-29 11:01 -0700

#18317 — thread vs fork?

hi, is fork runs faster then thread in java?
thanks
from Peter (cmk128@hotmail.com)

[toc] | [next] | [standalone]

#18318

In article <15cf029d-e8bc-47de-8b83-44e70247d381@googlegroups.com>,
 Peter Cheung <cmk128@gmail.com> 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>

[toc] | [prev] | [next] | [standalone]

#18319

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

[toc] | [prev] | [next] | [standalone]

#18350

On Sat, 25 Aug 2012 23:40:38 -0700 (PDT), Peter Cheung
<cmk128@gmail.com> 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 

[toc] | [prev] | [next] | [standalone]

#18359

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/api/java/util/concurrent/ForkJoinTask.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

[toc] | [prev] | [next] | [standalone]

#18374

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

[toc] | [prev] | [next] | [standalone]

#18376

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

[toc] | [prev] | [next] | [standalone]

#18377

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

[toc] | [prev] | [next] | [standalone]

#18400

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web