On 30/09/2013 8:06 AM, William ML Leslie wrote:
I think I would phrase 'the workarounds for I/O in ... STM' as 'unlike memory, optimistic rules for alias detection don't apply generally to IO',
Two points:1. Alias detection in memory doesn't even work that well; STM often relies on timeouts to avoid deadlock because ordering lock acquisition is too costly.
2. The predominant I/O to files is a historical artefact of Multics and the C programming language it eventually spurned. In principle, disk is just another level of the memory hierarchy, and we can push this all the way down to the OS as the orthogonal persistence in KeyKOS, EROS/CapROS and L4 have shown (and as E and Waterken show within safe language environments). Any properties we expect of in-memory objects thus also applies to I/O-level objects; we just hack around it via file system abstractions.
I agree that some of these problems can be mitigated as you suggest, ie. with more rigourous specification of IO, but why should I bother when other solutions don't have this problem and further provide even more compelling properties?
Furthering point 2 above, concurrent revisions and other related approaches [1], provides just such a unified view of all levels of a memory hierarchy. I recently came across [2] which purports to provide a more formal account of precisely why concurrent revisions and Bloom provide better fundamental abstractions. LVars are generalizations of futures permitting multiple assignments (monotonically increasing as determined by a user-specified lattice), thus automatically providing high availability and eventual consistency in the presence of partitions.
These are the sorts of properties that are actually important to express. I'm not impressed with my concurrency library imposing arbitrary restrictions on my IO when there are more important properties I need to concern myself with.
Sandro [1] http://www.bloom-lang.net/calm/[2] http://www.cs.indiana.edu/~lkuper/papers/lvars-fhpc13.pdf <http://www.cs.indiana.edu/%7Elkuper/papers/lvars-fhpc13.pdf>
and consequently, they deserve unique treatment and finer-grained control. There are many cases where IO can be decomposed into interactions with different services, but this is not always the case. For most STM systems, if they even provide a mechanism for defining distinct services (that is, a way to describe the implied partial order on IO effects or separate them out into different monads), it usually lives outside the language. I don't think these are problems with existing AME scheduling mechanisms, rather, they are a problem with a lack of specification of the various algebrae that comprise IO. --- Nevertheless, what Carmack seems to be describing is GC (with card tables, I guess). He wants more control, but like many, doesn't quite seem to grasp what that control needs to be. There are allocation patterns where lifetime is almost statically determined by control flow, programmers can see these clearly, but sometimes have trouble describing what these patterns are in a composable way. Such thinking is where systems like Rust and linear types come from, but neither feel like they describe the full picture.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
