chicken-users
[Top][All Lists]
Advanced

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

Re: [Chicken-users] Re: An alternative thread system?


From: Elf
Subject: Re: [Chicken-users] Re: An alternative thread system?
Date: Mon, 11 Aug 2008 15:23:22 -0700 (PDT)

On Tue, 12 Aug 2008, Aleksej Saushev wrote:

"Shawn Rutledge" <address@hidden> writes:

I'm inclined to agree with the argument that as long as forking has a
low enough overhead, processes are better than threads for
general-purpose parallelism.  Especially considering that if you are
using memory to share state between threads, you will always be
limited to a shared-memory architecture - you cannot move the program
unmodified onto a cluster.  But there is more data-copying involved
with message-passing, compared to just accessing the same memory.
Safety and portability have their price.

Your attitude to threads is just a prejudice with no support behind it.


Irrelevant personal attack without basis.

Most overhead originates not from fork, it comes from copying and IPC.
Passing data between threads may be as simple, as assignment. Note:
no context switch involved. Passing data between processes is almost
always two context switches, synchronization in kernel, and copying
passed data at least twice, unless you use some very system-specific
hack. Sometimes you can avoid redundant copying by mmaping common file,
which still brings you to shared-memory and all the stuff connected.
There's the price of your prejudices in terms of performace lost.


Show me some numbers to back this up.  Show me also how to pass data between
threads without mutexes (which block) (which cause context switches) in a
safe way.  Show me data.


If you work within properly choosen framework, you may care very little
about what you are running actually, a thread or a process on another
machine. Having one subroutine, that merely passes the pointer to locals
and communicate over network to remote, is easy enough, if you don't
pass linked structures.


Generally, you can only work on processes on some other machine, cause the thread model is going to be different and 9/10 times incompatible,
with a generous estimate.

Properly chosen framework.... find me a portable "properly chosen framework"
that works more on $(OS OF CHOICE). two unixes, macosx, and at least one modern (post 98) version of windows.


-elf





reply via email to

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