Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

multi-processed VS multi-threaded

111 views
Skip to first unread message

igotmumps

unread,
Feb 24, 2012, 11:33:37 AM2/24/12
to
I started this discussion on the GT.M groups page on LinkedIn, but it
doesn't seem to be getting much notice. Posting here hoping someone
can comment.

thanks....

Multi-processed vs Multi-Threaded
My naive understanding of the difference between Multi-processed and
multi-threaded applications is that multi-processed applications don't
share process state, and multi-threaded applications do. Am I correct
in my understanding of the two?

Also, it is my naive understanding that GT.M can do multi-processing,
but not multi-threading? Is this correct?

thanks for your help...

Michael

OldMster

unread,
Feb 24, 2012, 11:59:12 AM2/24/12
to
I don't claim to be an expert on the difference, but that is at least partly correct. The main difference as I understand it is that threads are supposedly more 'lightweight' and involve less startup overhead than a process. I really don't see any significant benefit to threads in an M system generally, but there may be some benefit in the new 'plugin' architecture that GT.M introduced.

Mark

K.S. Bhaskar

unread,
Feb 24, 2012, 1:14:23 PM2/24/12
to
GT.M does multi-processing but not multi-threading.

Regards
-- Bhaskar

Kang

unread,
Apr 19, 2012, 11:26:45 AM4/19/12
to
The differences between multi-process and multi-threading have to do
with how the O/S treats the process itself. When a single process is
created the O/S allocates a chunk of memory and a "process" structure;
the process structure allows the O/S to manage the process state. The
process memory is only accessible by that process itself; otherwise
all kinds of chaos would ensue. So if you are creating multiple
processes then each process gets these things. If you wanted to create
an app that performed multiple tasks concurrently, you would spawn new
processes via fork or use some other mechanism like shared memory or
pipes to cooperate/coordinate with each other.
NOTE: Shared memory is a mechanism that creates a chunk of memory that
is managed separately from the process; think of it as a file that has
some data in it that each process can access independently. Just
wanted to clarify that shared memory is *NOT* something that is added
to the existing process' memory already allocated by the Kernel.

A multi-threaded process is still just a single process, so you get
the same aforementioned things from the O/S, but the multiple threads
that are created within that single process can access all of the
process' memory space. The concept of multiple threads allows a single
process to execute multiple tasks concurrently, whereas a single
process has a single thread of execution that occurs. The O/S still
manages the process as if it is a single process, with the MT
libraries provide the controls for the internal task management.
Typically, multi-threaded processes are managed by a library, such as
pthreads in the Unix world.

Hope this helps.
0 new messages