On Tue, Dec 7, 2010 at 9:45 AM, Claudia Fohry <fo...@uni-kassel.de> wrote:
> Hi, > > according to the standard (p. 163), atomic is executed "as if in a single > step > during which all other concurrent activities in the same place are > blocked". > This is just a description of its behaviour. There are many semantics for atomic blocks, this is the simplest. I call it a 'stop the world semantics' but there might be a better name someone else is using. > Halting all other activities for all accesses to shared variables seems to > be > inefficient for any reasonable number of threads. > Yes that would be horrible > Is this implemented (or planned to be implemented) in a more efficient way > (and how)? It is currently implemented in a more efficient way -- with a single global lock. It is more efficient because not all of the activities are blocked -- only those that try to enter an atomic section while another activity is in an atomic section. This is only actually compatible with the stop the world semantics if all shared variable accesses are inside an atomic block. This is of course the difference between weak/strong semantics for atomic sections. We may well forget to mention that in the spec, in which case we should add it, because requiring strong semantics is way too restrictive. Or what else is the philosophy behind this design decision, e.g., > should one strive to have only very few threads per place, and instead use > multiple places per node? > Vijay ought to say something at this point. However I have been in the trenches of atomic sections implementation so I want to say something too. It seems to me that at the time when atomic was added to X10 at a time when there was a lot of healthy research into making their implementation faster and more general. However in the last few years we still haven't got to the point where atomic sections are clearly the silver bullet and there is a simple and efficient implementation that covers all bases. For a taster, we have: hardware transactional memory: typically limited in the number of variables that can be touched in an atomic section software transactional memory: high factors of performance loss due to instrumentation, weak semantics faster than strong semantics lock inference: lots of heavy compiler analysis required to get even moderate quality locks, very clever lock-based algorithms (e.g. hand-over-hand) are off the table I think the problem here is that there is no clear winner, which means a practical language is going to need a fusion of these things, and that makes things very complicated indeed. And on top of that, it's not clear that even such a fusion will provide programmers with an atomic section whose productivity gain offsets the performance cost (when compared with manual synchronisation). We haven't discussed much how to improve our atomic sections implementation, and we haven't done any original research on the matter afaik. It may be that the only way to move forward in the short term is to give programmers the ability to use both traditional synchronisation primitives (like Java) and atomic blocks. > Thanks for any help, > > Claudia > > ------------------------------------------------------------------------------ > What happens now with your Lotus Notes apps - do you make another costly > upgrade, or settle for being marooned without product support? Time to move > off Lotus Notes and onto the cloud with Force.com, apps are easier to > build, > use, and manage than apps on traditional platforms. Sign up for the Lotus > Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d > _______________________________________________ > X10-users mailing list > X10-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/x10-users > ------------------------------------------------------------------------------ What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d _______________________________________________ X10-users mailing list X10-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/x10-users
