Another bit of explanation. There is a lot of push in modern programming languages to embed concurrency support into the language and/or the language runtime. Tim Sweeney's talk (The Next Mainstream Programming Language -- you can google it) at POPL '06 seem to make a pretty typical case. In light of which, I want to explain why concurrency is *not* part of the BitC language specification.
There are two types of concurrency: local and global. While I believe Tim was thinking about concurrency more broadly, his slides only mentioned one concrete example: SIMD. Dealing with SIMD concurrency is pretty straightforward. It is mostly an optimizer problem. There are various things that the language can do to help, most notably in ensuring non-interference, and I think that BitC is doing most of that. The harder issue is the problem of non-local-scale concurrency. This really has two parts: - Means to declare which variables are thread-local (and therefore have no possibility of interference) - Concurrency control primitives The thread-local part is pretty straightforward. It's not currently in BitC, but it's a very easy thing to put in and we should do it. The part that really worries me is the concurrency control issues. Take as an example the Java object locks. The problem is that these handle 94% of the use cases very well, and completely screw the remaining cases. It isn't that locks are bad. The problem is that we don't *have* a universal concurrency model. So the position that I took in BitC was more or less: - Provide some compile-time support for isolation - Leave the concurrency control problem for the library. On reflection this is inadequate, because we really do know *something*about concurrency: all of the models that are deadlock-free impose hierarchies. Given this, it should be possible to associate fields and variables with a particular lock *without* specifying how that lock is implemented. Because concurrency is SO application dependent, I'm not entirely convinced that types are the best way to deal with it, but it's worth thinking about. For the moment, I don't think I have the answers on this. For that matter, I probably only have SOME of the questions. One thing does seem clear: we shouldn't build in to the language any policy about concurrency that isn't fairly well universal. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
