>>>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 >>>specification. [...] > On Wed, 2005-08-31 at 14:24 -0400, Mark Miller wrote: >>Yes. See Hans Boehm's "Threads Cannot be Implemented as a Library" >><http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html>. 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 >>>"done right." >> >>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 Cheers, --MarkM _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
