On 30/06/17 11:26, Alexander Monakov wrote: > On Fri, 30 Jun 2017, Richard Earnshaw (lists) wrote: >> Sorry, but it's *VERY* different. The options you mention will lead to >> a consisten run-time failure. >> >> Getting the atomicity wrong will lead to random failures at runtime that >> are almost impossible to track down due the nature of such race >> conditions. That's simply intolerable. > > But our current solution in libatomic: > > - may deadlock when atomic op is reentered via a signal frame; > > - doesn't synchronize between distinct processes operating on > atomic objects in shared memory; > > (this can lead to the same failure mode as in your objection btw, > it might seem to work >99% of time); > > - neither limitation appears to be documented in any obvious place. > > > I'd say what we do now is far more inexcusable. > These are both obvious limitations of objects that use locks. Users just have to be aware of such limitations. Documentation would certainly help. Your solution spreads the chaos further to include multithreaded programs with a single address space. It doesn't solve any of the above problems because some processes might still be using locks. R. > Alexander >
