> 1. Is 'atomic' construct an abstraction of transactional memory???!! Yes, in that a transactional memory approach could be used to implement the atomic construct. The semantics of atomic are deliberately vague to allow various implementations. There is a veritable zoo of potential implementation techniques, with wide ranging compiletime/runtime performance characteristics and tradeoffs, and no clear winner.
> 2.If the answer to the first question is yes, is it feasible for the development team to discuss the details of the implementation?? Currently, a per-place lock is used. The lock is acquired for the duration of the atomic section. Conditional atomic, i.e. 'when', is implemented using a single condition variable on this lock that is signalled on every exit from an atomic section. The implementation is a mixture of generated code and handwritten code in x10.lang.Runtime. Note that any attempt to change the implementation of atomic sections must also change the implementation of 'when'. >We are understanding the feasibility of implementing STM in X10. So, you details are most important for us. It is unlikely to be harder than implementing Java+atomic with STM. You could modify the Java or C++ codegen strategy in the backend of the x10c compiler to instrument accesses, detect collisions, and handle rollbacks. I can't think of any differences between X10 and Java that would be relevant in an STM implementation. Which variant of STM are you considering? ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ X10-users mailing list X10-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/x10-users
