[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re Re: :zz: "!@#$% General DATA solution impossible
- To: "Mark S. Miller" <markm@xxxxxxxxxx>, zzdev@xxxxxxxxxx
- Subject: Re Re: :zz: "!@#$% General DATA solution impossible
- From: Ted Nelson <ted@xxxxxxxxxx>
- Date: Mon, 12 Apr 1999 00:32:18 +0900
- Cc: ted@xxxxxxxxxxxxxx
- In-reply-to: <4.1.19990406115003.009d1ed0@xxxxxxxxxxxx>
- References: <3.0.6.32.19990403180739.009a3360@xxxxxxxxxxxxxxxxxxx> <19990403111002.B749@xxxxxxxxxxxxxxxxx> <3.0.6.32.19990402231020.0079c330@xxxxxxxxxxxxxxxxxxx> <3.0.6.32.19990402080942.0099a100@xxxxxxxxxxxxxxxxxxx> <3.0.6.32.19990331143342.0092e8c0@xxxxxxxxxxxxxxxxxxx> <3.0.6.32.19990331005450.007ffa90@xxxxxxxxxxxxxxxxxxx> <3.0.6.32.19990331005450.007ffa90@xxxxxxxxxxxxxxxxxxx> <19990331024514.H9852@xxxxxxxxxxxxxxxxx> <3.0.6.32.19990331143342.0092e8c0@xxxxxxxxxxxxxxxxxxx> <19990331164928.B10875@xxxxxxxxxxxxxxxxx> <3.0.6.32.19990402080942.0099a100@xxxxxxxxxxxxxxxxxxx> <19990402094635.A520@xxxxxxxxxxxxxxxxx> <3.0.6.32.19990402231020.0079c330@xxxxxxxxxxxxxxxxxxx>
- Reply-to: zzdev@xxxxxxxxxx
Hi Mark--
The problem isn't concurrency. The problem is the
complex tissue structure of ZigZag. If each process
is just creating an independent file or well-expected datum,
there's no problem. However, each process in a parallel ZZ
could rip the tissue in another direction.
Another way to put it: data in ZigZag is in some sense global.
A *non-general* solution will allow each process to create
its own unconnected cell, rank, grid, etc. The problem is
the connections and keeping them from messing each other up.
A wonderful image just occurred to me: a lot of berserk
sewing machines on wheels, stitching everything in your
closet together chaotically.
Best, T
At 11:58 AM 4/6/99 -0700, you wrote:
>At 02:07 AM 4/3/99 , Ted Nelson wrote:
>>You said:
>>>I don't presently see any simple solution for the general case, except
>>>to note that these are traditional problems of parallelism ...
>>
>>The reason is that if we aren't seriously simplifying
>> in some original way, maybe we shouldn't be doing it.
>
>E's concurrency control model, derived from Actors, FCP, and Joule
>http://www.agorics.com/joule.html but reconciled with sequential
>programming, is a solution to the general concurrency control problem that's
>much simpler and more robust than the thread/locking model. Unfortunately,
>I haven't adequately documented this model yet, but see
>"http://www.erights.org", especially
>"http://www.erights.org/elib/concurrency/index.html" and
>"http://www.erights.org/elib/concurrency/vat.html". My guess is that all
>this would apply perfectly well to zigzag.
>
>
> Cheers,
> --MarkM
>
>
>
____________________________________________________
Theodor Holm Nelson, Visiting Professor of Environmental Information
Keio University, Shonan Fujisawa Campus, Fujisawa, Japan
Home Fax from USA: 011-81-466-46-7368 (If in Japan, 0466-46-7368)
http://www.sfc.keio.ac.jp/~ted/ (Professorial page)
_____________________________________________________
Permanent: Project Xanadu, 3020 Bridgeway #295, Sausalito CA 94965
Tel. 415/ 331-4422, fax 415/332-0136
http://www.xanadu.net (see also Professorial page, above)
PERMANENT E-MAIL: ted@xxxxxxxxxx
_____________________________________________________
QOD 99.03.31
"Everything is like everything else, but some of the resemblances are
harder to see." TN99