[bitc-dev] Representation and memory model
markm at cs.jhu.edu
Wed Aug 31 15:54:02 EDT 2005
>>>On Thu, 2005-09-01 at 00:57 +0700, Constantine Plotnikov wrote:
>>>[...] it is possible to write multithreaded programs
>>>>using [C]. [...]
>>Jonathan S. Shapiro wrote:
>>>[...] It is also true that
>>>these codes rely on behavior that is NOT part of the language
> On Wed, 2005-08-31 at 14:24 -0400, Mark Miller wrote:
>>Yes. See Hans Boehm's "Threads Cannot be Implemented as a Library"
Jonathan S. Shapiro wrote:
> Can you expand on this? Which direction is your point supporting?
Yours. It is not possible to write multithreaded programs using C. The fact
that people do it anyway does not establish that it is possible ;).
>>>1. We have never seen a language concurrency model that we think was
>>Ahem, cough cough, ah, over here, [gesticulates wildly while pointing], ...
> Respectfully, in my opinion, no. "E the system" has a concurrency model
> that I think is done right for many purposes (though I am skeptical
> about its relevance in something like a kernel).
I agree it would be a terrible choice for a kernel, for precisely the same
reason that relying on gc would be terrible for a kernel. But for those apps
that do use gc...
But I wasn't particularly advocating the E model for bitc. Merely reacting to
'We have never seen a language concurrency model that we think was
"done right".'. Whether E's model is right for your purposes is another matter.
IMO, Actors, Flat Concurrent Prolog, and especially Joule also do concurrency
right, but probably once again not right for your purposes.
> This is so precisely because "E the language" explicitly excludes any
> concurrency at all from the specification -- the goal being
> deterministic execution.
I'm not sure I draw the same line between "language" and "system" that you do.
But no matter, that's just terminology. E seeks to be deterministic within a
turn. For the part of the E system that does specify concurrency, ideally, as
with Actors, the only remaining irreducible non-determinism would be
arrival-order non-determinism: the non-deterministic order in which messages
sent by other vats are interleaved as they arrive at a given vat.
(In fact, there are remaining sources of non-determinism, such as the clock or
the ability to detect that something's been gc'ed, but these are only
available to those with access to non-widely-held capabilities.)
Text by me above is hereby placed in the public domain
More information about the bitc-dev