Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!fas-news.harvard.edu!newspump.wustl.edu!gumby!newsxfer.itd.umich.edu!gatech!newsfeed.pitt.edu!uunet!world!edwards
From: edwards@world.std.com (Jonathan Edwards)
Subject: Re: Multithreading & multiprocessing
Message-ID: <D25yI3.12y@world.std.com>
Organization: IntraNet, Inc.
References: <D1ypys.8G5@world.std.com> <9501091643.AA28831@rhiannon.inference.com>
Date: Tue, 10 Jan 1995 00:25:15 GMT
Lines: 29

In article <9501091643.AA28831@rhiannon.inference.com>,
Robert W. Kerns <rwk@inference.com> wrote:
>Surely you jest!  First, neither of these are part of C++, and
>the problems C++ has with multi-processing are far more fundamental.
>For example, there is no guarentee that *ANYTHING* in particular is
>atomic.  For example, var = 5.0; may involve two instructions, or
>an instruction which does two uninterlocked memory write cycles.

Much as I hate to defend C++, I think this is unfair.
Even in assembly language you can not depend on atomic updates:
there are issues of data allignment and cache coherency. Code that depends on
this (and I have written it, BTW) is awfully fragile.
The point of a threading model is to make it easy to synchronize data access
through semaphores and related synchronziation primitives at a higher level.
Since C++ is the moral equivalent of object-oriented assembly language, it is
really very easy to make multithreaded, and both Sun and Microsoft have done
this. Microsoft even has added thread-local storage to the language.


C++: Just Say --





-- 
Jonathan Edwards				edwards@intranet.com
IntraNet, Inc					617-527-7020
One Gateway Center				FAX: 617-527-6779
