On Thu, 14 Apr 2005 23:11:03 -0400, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Again, not always. Consider chaotic asynchronous algorithms > (like variations of simulated annealing). They need no locks nor > any other kind of synchronization, though sometimes they'll use > some form of control synchronization to delimit phases. > > When implementing them in a shared-memory multithreaded > environment, they typically mark shared data as 'volatile' to > prevent the compiler from optimizing those references away. The properties of asynchronous algorithms are independent of memory model; even asynchronous algorithms expect to get updates from other threads all at once. If one thread writes out a new data set and another thread reads in an arbitrary subset of it, thinking it is the complete set, the algorithm will break. With a weak memory model, some sort of explicit memory ordering is necessary to ensure that all writes to that area are visible before reads begin. I believe that the current standard volatile semantics mean that if you mark all shared data as volatile, you enforce sequential access to all shared data, which will accomplish the necessary ordering but is stronger than you need. With the proposal only the last write and first read from the data need to be volatile, and the compiler and machine have more freedom to reorder the other accesses. I also believe that current compilers don't actually implement my interpretation of current semantics on most targets, and as a result marking the shared data as 'volatile' does not accomplish the necessary memory ordering, and the algorithm is likely to break without memory barrier asms. I think that with most compilers 'volatile' restricts reordering by the compiler, but not by the hardware, and so code that relies on 'volatile' alone will break on targets with a weak memory model. You seem to be conflating synchronization (via locks or otherwise) with explicit memory ordering; they are not the same. Synchronization involves threads waiting for each other to catch up; this proposal just means that at a release point all pending memory accesses are visible before a volatile write, and a volatile read happens before all subsequent memory accesses. This is strictly a thread-local property, and does not imply any waiting on another thread. I suppose using the terms 'acquire' and 'release' mislead people to think about locks, when no locks or other synchronization are implied. Some sort of coherent memory ordering is necessary for synchronization, but it is also necessary for asynchronous algorithms. > Right, but it would take away the traditional semantics of volatile. Why > not use some new language construct (monitors, set/wait) or even > templates to implement synchronization? Yes, actual synchronization is properly implemented by a library. > That's the only thing that I find disturbing about the proposal. > Overloading a very well established keyword with a new meaning. > I don't think it's going to be well received, that's all. Because it's very close to the current semantics, which IMO already impose ordering on volatile accesses (though compilers don't enforce that). The change is to define how volatile accesses are ordered relative to non-volatile accesses. I don't think it's a large conceptual change. A naive implementation would result in more overhead, but we should be able to optimize most of it away. > http://www.cs.ualberta.ca/~jonathan/Grad/Papers/aphidiee.ps > http://web.nchu.edu.tw/~jlu/research/papers/asynch.ps > > Note that the initial motivation for many of these techniques was to > yield good results on distributed systems. But if you were to implement > them in a multithreaded environment with shared data instead of message > passing, they'd declare the shared data volatile. Again, I don't think this is enough with current compilers and hardware. And with the proposal only the flag which indicates that a new data set is ready would need to be volatile. Jason
