|
Home > Archive > Unix Programming > March 2004 > concurrent process vs. parallel process
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
concurrent process vs. parallel process
|
|
|
| Hi all,
I'm having confusion understanding the differences between concurrent
and parallel processes (or programs). As far as I understand, parallel
processing is simultaneous use of more than one CPU to execute a
program, thus "dividing" a program to be executed by disparate CPUs.
Now what exactly is concurrent process? Is it similar as
multithreading? Are these terms used interchangeably?
I searched on google for definition of concurrent processing but was
unable to get a convincing one. If you guys know of good sites that
explain concurrent processing, please let me know.
Thanx for your time!
Ben
| |
| Christopher Benson-Manica 2004-03-13, 10:34 pm |
| In comp.lang.c Ben <crescent_au@yahoo.com> wrote:
^^^^^^^^^^^
> I searched on google for definition of concurrent processing but was
> unable to get a convincing one. If you guys know of good sites that
> explain concurrent processing, please let me know.
comp.lang.c readers would be grateful to have that group removed from
followups to this post, as it isn't topical on comp.lang.c. Thanks.
OP: Sometimes crossposting is appropriate, but you've overdone it
here.
--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
| |
| Barry Margolin 2004-03-13, 10:34 pm |
| In article <d99e1341.0403131717.2d8bcd69@posting.google.com>,
crescent_au@yahoo.com (Ben) wrote:
> Hi all,
>
> I'm having confusion understanding the differences between concurrent
> and parallel processes (or programs). As far as I understand, parallel
> processing is simultaneous use of more than one CPU to execute a
> program, thus "dividing" a program to be executed by disparate CPUs.
> Now what exactly is concurrent process? Is it similar as
> multithreading? Are these terms used interchangeably?
Concurrent processing usually refers to timesharing a single CPU among
multiple processes or threads. This gives the illusion of parallel
processing even though no two of them are ever really running at the
same time.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| Nick Landsberg 2004-03-13, 11:34 pm |
| Barry Margolin wrote:
> In article <d99e1341.0403131717.2d8bcd69@posting.google.com>,
> crescent_au@yahoo.com (Ben) wrote:
>
>
>
>
> Concurrent processing usually refers to timesharing a single CPU among
> multiple processes or threads. This gives the illusion of parallel
> processing even though no two of them are ever really running at the
> same time.
>
In addition to what Barry said,
on Multi-CPU hardware, it actually may
be concurrent processing, as different programs/threads will
run on different CPU's within the same phycial
harware "box".
Another way to differentiate the "parallel" vs.
"concurrent" processing modes is that, in true
parallel processing, each CPU is working on a subset
of the problem (e.g. trying to find factors of
a candidate prime), while in concurrent processing,
each CPU is usually working on a different problem
(e.g. trying to find factors of different
candidate primes).
What I describe above are what I would call "compute
intensive" programs. Multi-threading (IMHO) is most
effective when the program is NOT compute intensive
but must wait on some events, like disk reads.
While one program (or thread) is waiting on data from
the disk, another program is given the opportunity
to run, until it too waits for some event to happen
(perhaps a network read), etc., etc.
Multi-threading of compute intensive programs
actually slows the processing down on a single
CPU system. (And even on Multi-CPU systems,
it's effectiveness is limited by the
number of CPU's one can bring to bear.
Running 50 compute-intensive threads on
a 4 CPU box doesn't buy you much, if it buys
you anything at all.)
--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
| |
| Jack Klein 2004-03-14, 12:33 am |
| On 13 Mar 2004 17:17:37 -0800, crescent_au@yahoo.com (Ben) wrote in
comp.lang.c:
> Hi all,
>
> I'm having confusion understanding the differences between concurrent
> and parallel processes (or programs). As far as I understand, parallel
> processing is simultaneous use of more than one CPU to execute a
> program, thus "dividing" a program to be executed by disparate CPUs.
> Now what exactly is concurrent process? Is it similar as
> multithreading? Are these terms used interchangeably?
>
> I searched on google for definition of concurrent processing but was
> unable to get a convincing one. If you guys know of good sites that
> explain concurrent processing, please let me know.
>
> Thanx for your time!
> Ben
Why did you cross-post this to comp.lang.c, where it is completely
off-topic?
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~.../FAQ-acllc.html
| |
| Rich Teer 2004-03-14, 12:33 am |
| On Sun, 14 Mar 2004, Jack Klein wrote:
> Why did you cross-post this to comp.lang.c, where it is completely
> off-topic?
Probably because he didn't know. BTW, judging by his response
to the OP's post, Christopher Benson-Manica is a much better
ambassador for c.l.c. Try taking a hint from his "friendly
chastisement" book...
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| David C. DiNucci 2004-03-14, 1:33 am |
| Nick Landsberg wrote:
>
> Barry Margolin wrote:
>
> In addition to what Barry said,
> on Multi-CPU hardware, it actually may
> be concurrent processing, as different programs/threads will
> run on different CPU's within the same phycial
> harware "box".
>
> Another way to differentiate the "parallel" vs.
> "concurrent" processing modes is that, in true
> parallel processing, each CPU is working on a subset
> of the problem (e.g. trying to find factors of
> a candidate prime), while in concurrent processing,
> each CPU is usually working on a different problem
> (e.g. trying to find factors of different
> candidate primes).
I would be careful with both "usually"s above. The word "concurrent",
of course, means nothing more than "occurring at the same time", and the
word "parallelism" has no such well-defined etymology, just a suggestion
that things are running alongside one another, perhaps in a space/time
diagram, so I (and presumably othes) take it to imply a relationship in
space (not colocated) as well as time (concurrent). Though I don't
pretend to have or use an authoritative definition, I know that I
personally tend to use the words almost interchangeably, sometimes
preferring concurrency when I want to refer to the *ability* of
operations to run at the same time (e.g. due to their independence), and
preferring parallelism when I want to refer to the *necessity or desire*
for them to run at the same time--which naturally implies a greater
value of giving each its own resources.
-- Dave
-----------------------------------------------------------------
David C. DiNucci Elepar Tools for portable grid,
dave@elepar.com http://www.elepar.com parallel, distributed, &
503-439-9431 Beaverton, OR 97006 peer-to-peer computing
| |
| CBFalconer 2004-03-14, 3:34 am |
| Rich Teer wrote:
> On Sun, 14 Mar 2004, Jack Klein wrote:
>
>
> Probably because he didn't know. BTW, judging by his response
> to the OP's post, Christopher Benson-Manica is a much better
> ambassador for c.l.c. Try taking a hint from his "friendly
> chastisement" book...
And while both of you were responding, why didn't you set
follow-ups to eliminate c.l.c, as did Christopher and myself?
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
| |
| Nick Maclaren 2004-03-14, 6:33 am |
| In article <92f78472096097df4441459128d7666f@news.teranews.com>,
Jack Klein <jackklein@spamcop.net> wrote:
>On 13 Mar 2004 17:17:37 -0800, crescent_au@yahoo.com (Ben) wrote in
>comp.lang.c:
>
>
>Why did you cross-post this to comp.lang.c, where it is completely
>off-topic?
Well, I am not going to justify his excessive cross-posting of a
non-trivial but basic question, but the issue is most definitely NOT
off-topic for comp.lang.c!
There are some VERY serious problems with incompatibilities between
the architectural models used by C, POSIX threads and OpenMP - and,
to a slightly lesser extent, Fortran and MPI - and I spent some time
trying to get ANY of the relevant standardisation groups to take the
issues on. All of them admitted that the issues were real and serious,
but were Someone Else's Problem.
The only significant progress in this area since the beginning of
those projects has been in Fortran 200x, and it is a pretty trivial
one. I am uncertain in my own mind whether it is even POSSIBLE to
get very far with integrating the C, POSIX threads and OpenMP models
(or even just any two of them!)
Howewer, I doubt VERY much that the original poster was asking for
a description of the issues at the level I am describing :-)
Regards,
Nick Maclaren.
| |
| Irrwahn Grausewitz 2004-03-14, 7:35 am |
| nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
>In article <92f78472096097df4441459128d7666f@news.teranews.com>,
>Jack Klein <jackklein@spamcop.net> wrote:
[ concurrent process vs. parallel process ]
<snip>
[color=darkred]
>
>Well, I am not going to justify his excessive cross-posting of a
>non-trivial but basic question, but the issue is most definitely NOT
>off-topic for comp.lang.c!
Sorry, but you are clearly mistaken. In c.l.c only the C
language as defined by the standard(s) is discussed. Since
the C standard has no notion of concurrent or parallel
processes (it does not even mention the terms, BTW), OP's
question is off-topic by definition.
If you want to make a proposal about the issue to be
addressed in a future revision of the C standard, please
post it to comp.std.c, where it would be on-topic.
<snip>
Regards
--
Irrwahn Grausewitz (irrwahn33@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~.../FAQ-acllc.html
| |
| Nick Maclaren 2004-03-14, 8:35 am |
| In article <m0h8505rcpiebftbnggsgcs96t4cmo7f6k@4ax.com>,
Irrwahn Grausewitz <irrwahn33@freenet.de> wrote:
>nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
>
>[ concurrent process vs. parallel process ]
>
>
>Sorry, but you are clearly mistaken. In c.l.c only the C
>language as defined by the standard(s) is discussed. Since
>the C standard has no notion of concurrent or parallel
>processes (it does not even mention the terms, BTW), OP's
>question is off-topic by definition.
I was under the impression that comp.lang.c bore some relevance to
the language C as it is used on current systems, but you seem to
disagree. Others may disagree with you :-)
Perhaps I should point out that the concurrent/parallel aspects of
C are only one of MANY important aspects that are undefined in the
standards (pretty well all of them, and there are more than you
might think). Other aspects that are very comparable include all
(real) signal handling, almost all error handling (especially I/O),
and even the details of floating-point and locale support.
>If you want to make a proposal about the issue to be
>addressed in a future revision of the C standard, please
>post it to comp.std.c, where it would be on-topic.
I suggest that you go back and read the rest of my posting, which
might hint to you that I have made just such proposals in slightly
more relevant and official contexts than comp.std.c.
The reason that this is relevant to comp.arch is that the FIRST
thing we need to address this fiasco is a architecture for data
access consistency, at a suitable level to form a basis for language
standardisation. But, as I said, I have failed to persuade any of
the relevant groups to take this on board.
Regards,
Nick Maclaren.
| |
| Irrwahn Grausewitz 2004-03-14, 10:34 am |
| nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
>In article <m0h8505rcpiebftbnggsgcs96t4cmo7f6k@4ax.com>,
>Irrwahn Grausewitz <irrwahn33@freenet.de> wrote:
[Still cross-posting, since I don't know in which group
you are following this thread; probably c.a., but just
guessing...]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
>I was under the impression that comp.lang.c bore some relevance to
>the language C as it is used on current systems, but you seem to
>disagree.
No, you just made my point: comp.lang.c is concerned about the
_language_ C as defined by the standard, whereas comp.std.c is
concerned about the _standard_, by which the C language is
defined.
>Others may disagree with you :-)
I'd be surprised to find [m]any c.l.c regulars among those. :-)
>Perhaps I should point out that the concurrent/parallel aspects of
>C are only one of MANY important aspects that are undefined in the
>standards (pretty well all of them, and there are more than you
>might think). Other aspects that are very comparable include all
>(real) signal handling, almost all error handling (especially I/O),
>and even the details of floating-point and locale support.
Which is why all of this is off-topic in c.l.c, but perfectly
on-topic in standardization and/or implementation-specific
news-groups.
[color=darkred]
>I suggest that you go back and read the rest of my posting, which
>might hint to you that I have made just such proposals in slightly
>more relevant and official contexts than comp.std.c.
I do not know of places where changes or additions to the C
standard would be more relevant than in c.s.c, except the
standardization committee itself. ;-)
>The reason that this is relevant to comp.arch is that the FIRST
>thing we need to address this fiasco is a architecture for data
>access consistency, at a suitable level to form a basis for language
>standardisation. But, as I said, I have failed to persuade any of
>the relevant groups to take this on board.
Please don't get me wrong: It's not that I don't understand your
motivation, or don't appreciate your efforts, it's just a fact
that attempts to discuss such issues in com.lang.c tend to turn
out as a waste of time and energy: if your proposals have already
been rejected in comp.std.c, there's no point to take them to
comp.lang.c.
Regards
--
Irrwahn Grausewitz (irrwahn33@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~.../FAQ-acllc.html
| |
| Richard Heathfield 2004-03-14, 11:35 am |
| [Followups set to comp.lang.c]
Irrwahn Grausewitz wrote:
> nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
>
> [Still cross-posting, since I don't know in which group
> you are following this thread; probably c.a., but just
> guessing...]
>
>
>
>
> No, you just made my point: comp.lang.c is concerned about the
> _language_ C as defined by the standard, whereas comp.std.c is
> concerned about the _standard_, by which the C language is
> defined.
>
>
> I'd be surprised to find [m]any c.l.c regulars among those. :-)
>
>
> Which is why all of this is off-topic in c.l.c, but perfectly
> on-topic in standardization and/or implementation-specific
> news-groups.
Right.
>
> I do not know of places where changes or additions to the C
> standard would be more relevant than in c.s.c, except the
> standardization committee itself. ;-)
Well, that might not be a complete coincidence. Nick is on the
standardization committee for C.
--
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
| |
| Jack Klein 2004-03-14, 1:35 pm |
| On Sun, 14 Mar 2004 04:57:30 GMT, Rich Teer <rich.teer@rite-group.com>
wrote in comp.lang.c:
> On Sun, 14 Mar 2004, Jack Klein wrote:
>
>
> Probably because he didn't know. BTW, judging by his response
> to the OP's post, Christopher Benson-Manica is a much better
> ambassador for c.l.c. Try taking a hint from his "friendly
> chastisement" book...
There was no chastisement, friendly or otherwise, in my response. It
was a question, and completely neutral.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~.../FAQ-acllc.html
| |
| Adam Chlipala 2004-03-14, 2:34 pm |
| Many people define "concurrent programming" as a style of programming
where a program is made up of many _conceptually_ concurrent processes.
Even if you end up running the program by multiplexing a single
processor, you can still benefit from the modularity of concurrent
processes in the same way that you can benefit from using, for example,
object-oriented techniques. For a great example, see Concurrent ML at
http://cml.cs.uchicago.edu/ .
| |
| Ketil Malde 2004-03-14, 3:35 pm |
| Irrwahn Grausewitz <irrwahn33@freenet.de> writes:[color=darkred]
> nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
[lots of stuff]
Now that we all know what is, and what is not on topic for the
comp.*.c groups, could the topicity police perhaps explain why this
discussion is on-topic in the rest of the groups it is posted to?
Thanks,
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
| |
| Rich Teer 2004-03-14, 3:35 pm |
| On Sun, 14 Mar 2004, Jack Klein wrote:
> There was no chastisement, friendly or otherwise, in my response. It
> was a question, and completely neutral.
My apologies; given the denzien's of c.l.c. usual response to
OT traffic, I read into your post a chastising tone.
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| Irrwahn Grausewitz 2004-03-14, 3:35 pm |
| Ketil Malde <ketil@ii.uib.no> wrote:
>Irrwahn Grausewitz <irrwahn33@freenet.de> writes:
<snip>
>[lots of stuff]
>
>Now that we all know what is, and what is not on topic for the
>comp.*.c groups, could the topicity police perhaps explain why this
>discussion is on-topic in the rest of the groups it is posted to?
Can you imagine why I started the post you are replying to
with the following disclaimer?
IG> [Still cross-posting, since I don't know in which group
IG> you are following this thread; probably c.a., but just
IG> guessing...]
And since I cannot tell where _you_ are reading this, and _you_
did not restrict the newsgroup- and fup'2-fields in the headers
to c.l.c (where I am reading your post, as you happen to know)
and whatever group you are reading this (you didn't actually tell
me, did you?), it still applies. What was your point, then?
(BTW, what's the meaning of "topicity"?)
>Thanks,
You're welcome,
Regards
--
Irrwahn Grausewitz (irrwahn33@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~.../FAQ-acllc.html
| |
| Ketil Malde 2004-03-14, 3:35 pm |
| Irrwahn Grausewitz <irrwahn33@freenet.de> writes:
> Can you imagine why I started the post you are replying to
> with the following disclaimer?
Well, yes. And I don't mind the odd diversion into off-topic
subjects. I'm just fascinated that a single arguably-on-topic post
can spawn a long thread on the exact rules -- which certainly in not
within the charter for any of the groups.
(And while I responded to your post in particular, I intended to
comment on the thread in general - my apologies, if that wasn't
clear.)
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
| |
|
|
|
| Jack Klein <jackklein@spamcop.net> wrote in message news:<92f78472096097df4441459128d7666f@news.teranews.com>...
>
> Why did you cross-post this to comp.lang.c, where it is completely
> off-topic?
well, my reason for posting it in c.l.c is:
C is a fairly popular language and i guessed most concurrent and
parallel programming has been done in C. So I thought C programmers
are one group of people who may have good understanding of these
topics. I could be wrong in thinking this but that's what i thought
when I posted. Lets not take it seriously. If you think it's been
off-topic, just ignore it...
Thanx for replies!
Ben
| |
| Alexander Terekhov 2004-03-16, 5:36 am |
|
Nick Maclaren wrote:
[...]
> Well, I am not going to justify his excessive cross-posting of a
> non-trivial but basic question, but the issue is most definitely NOT
> off-topic for comp.lang.c!
A bunch of groups (c.p.t., c.s.c, c.l.c++) added.
>
> There are some VERY serious problems with incompatibilities between
> the architectural models used by C, POSIX threads and OpenMP - and,
> to a slightly lesser extent, Fortran and MPI - and I spent some time
> trying to get ANY of the relevant standardisation groups to take the
> issues on. All of them admitted that the issues were real and serious,
> but were Someone Else's Problem.
Well,
http://groups.google.com/groups?thr...%40newsfep2-gui
(Subject: Re: Memory isolation)
<excerpt>
First, I note that the discussion again mutated to avoiding
sharing of cache lines rather than just to achieve isolation.
All the platforms I've examined seemed on casual analysis
(I am not a hardware expert) *not* to require avoidance of
cache line sharing in order to achieve isolation. Cache
line sharing was undoubtedly a real performance issue,
but it wasn't a correctness issue since they all implemented
some form of cache coherency. The isolation issues arose
from the non-availability of instructions addressing part-
words.
I am really interested to see if this casual conclusion
holds for the vast majority of platforms. On the principle
that the surest way of getting good information on
Usenet is to post an incorrect statement and wait for
the corrections I put it bluntly:
There is no existing platform that requires cache line
sized alignment for isolation. A variable is always
isolated from every other variable provided it does
not share any words with any other variable, where
a word just means the natural data word size for the
platform.
(I wrote something similar, but less strong, earlier
in the thread and no-one contradicted me.)
Second, using unions in this way is problematic in
C++ because [C++ standard 9.5/1]:
"...An object of a class with a non-trivial constructor (12.1),
a non-trivial copy constructor (12.8), a non-trivial destructor
(12.4), or a non-trivial copy assignment operator (13.5.3,
12.8) cannot be a member of a union, nor can an array of
such objects..."
Classes that have one or more of these forbidden
characteristics are of couse very common in C++
programming. So, it is not a general solution.
Third, how are we supposed to align a variable that
might be larger than a cache line? If we do,
typedef union {
ext_cache_line_aligned_t dummy;
struct large_struct data;
} cla_large_struct;
it won't necessarily work, since large_struct could
be 1.5 cache lines in size and thus not guaranteed
isolated from variables placed after it in memory.
If we have to create a separate CLA union for every
fundamental type member of a struct when we only
want the struct to be isolated as a whole (i.e. it
doesn't matter if members of the struct are not
isolated from each other), this will be very wasteful
of memory. (And of course we are assuming that
the size of each fundamental type is <= to the size
of a cache line.)
Lastly, even in C, if this is the sole way of achieving
isolation, it is either used for the declarations of every
variable in the program or some variables will not be
guaranteed, portably, to be isolated. As noted before,
a non-isolated variable is a dangerous thing, which is
why I believe that a future language standard should
make isolation guarantees for all variables. Not that
this means every variable should be guaranteed
isolated from every other variable, for example for a
struct member it could be as weak as "this variable
is isolated from all variables except for those that are
members of the same struct".
For your information, this subject was discussed at
the last meeting of the British C++ standards panel,
and the consensus seemed to be that it was an issue
worth pursuing further. This doesn't mean it will be
dealt with by the next C++ standard, but it is one step
closer. Whatever happens, I will keep this group
informed.
</excerpt>
That was written many moons ago. Nothing happened, AFAIK.
regards,
alexander.
| |
| Nick Maclaren 2004-03-16, 6:35 am |
|
In article <4056D4EB.830751@web.de>,
Alexander Terekhov <terekhov@web.de> writes:
|> Nick Maclaren wrote:
|> [...]
|> > Well, I am not going to justify his excessive cross-posting of a
|> > non-trivial but basic question, but the issue is most definitely NOT
|> > off-topic for comp.lang.c!
|>
|> A bunch of groups (c.p.t., c.s.c, c.l.c++) added.
Even though you are right that this is relevant to all of those
groups, such wide crossposting normally causes more confusion than
it is worth. I have set followups to comp.programming.threads.
|> http://groups.google.com/groups?thr...%40newsfep2-gui
|> (Subject: Re: Memory isolation)
|>
|> <excerpt>
|>
|> First, I note that the discussion again mutated to avoiding
|> sharing of cache lines rather than just to achieve isolation.
|> All the platforms I've examined seemed on casual analysis
|> (I am not a hardware expert) *not* to require avoidance of
|> cache line sharing in order to achieve isolation. Cache
|> line sharing was undoubtedly a real performance issue,
|> but it wasn't a correctness issue since they all implemented
|> some form of cache coherency. The isolation issues arose
|> from the non-availability of instructions addressing part-
|> words.
That is not the main architectural issue, which is that the
languages and other specifications (often including the hardware
architectures) do not have a clear model of when actions should be
seen by other threads. Cache coherence is nowhere near enough;
there is also memory access sequencing, register/cache consistency
issues, atomicity issues (in many forms) and so on.
Without a clear model, the 'debate' goes nowhere.
|> There is no existing platform that requires cache line
|> sized alignment for isolation. A variable is always
|> isolated from every other variable provided it does
|> not share any words with any other variable, where
|> a word just means the natural data word size for the
|> platform.
The first sentence may be right; the second is not. As a simple
counter-example, consider systems that permit unaligned memory
accesses. There are others.
|> That was written many moons ago. Nothing happened, AFAIK.
Yes. The problem is that there is necessarily no solution that
can be simply bolted on to C, C++, Fortran or even current
register- and cache-line-based hardware architectures.
Regards,
Nick Maclaren.
| |
| Hirajoshi 2004-03-16, 11:40 am |
|
"Ben" <crescent_au@yahoo.com> escribió en el mensaje
news:d99e1341.0403131717.2d8bcd69@posting.google.com...
> Hi all,
>
> I'm having confusion understanding the differences between concurrent
> and parallel processes (or programs). As far as I understand, parallel
> processing is simultaneous use of more than one CPU to execute a
> program, thus "dividing" a program to be executed by disparate CPUs.
> Now what exactly is concurrent process? Is it similar as
> multithreading? Are these terms used interchangeably?
>
> I searched on google for definition of concurrent processing but was
> unable to get a convincing one. If you guys know of good sites that
> explain concurrent processing, please let me know.
>
> Thanx for your time!
> Ben
Concurrent an parallel processes are completely different in their
definition, however they
have some things in common.
As somebody posted, concurrent means "happening at he same time" but
concurrent
programming and concurrent processes are much more about "accessing at the
same things
at the same time".
When you launch a hypercube of threads to solve a problem, you have to be
carefull if those
threads share memory and try to access it at the same time, those are the
main issues about
concurrency problems...
Concurrent and parallel processing are brothers because you can convert a
concurrent program
into a parallel program very easily, you only need a bunch of CPUs and make
each one of your
threads or processes go to a different CPU and get executed there, while in
the concurrent version
it was the scheduler of the OS who gave CPU to the different threads...
Anyway, the main problems with concurrent programing and processing are
about having a limited
resource accessed by N threads or processes, that is dangerous and thats why
it need process
synchronization politics, such as barriers, semaphores or monitors...
I hope this can help a little bit.
________________________________________
_______
Best regards,
José Fortes. Computer Engineer.
|
|
|
|
|
