The only thing that I find invaluable when in comes to concurrency is having a well defined memory model.
This is one of the major burdens to write wait free algorithms in C and C++. Without a proper memory model you have to be on the safe side, which is very expensive. On Fri, Dec 12, 2008 at 2:41 PM, Jonathan S. Shapiro <[email protected]>wrote: > 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 > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
