Hmmm, do you mean here that they instate memory barriers to ensure that those instructions aren't reordered or missed in a cache on another node/thread? I thought Terracotta didn't do anything transaction-related (isolation, commit-rollback, ...)?
On 07 Sep 2007, at 07:50, Steven Harris wrote: > concurrent locks provide transaction boundaries with no locking. In > that sense they are miss-named because > they aren't actually locks > > On Sep 6, 2007, at 10:47 PM, Geert Bevin wrote: > >> In general, one thing I've been wondering about: what's the >> difference between using concurrent locks and using no locking at >> all? >> >> On 07 Sep 2007, at 02:58, Gary Keim wrote: >> >>> Currently only read and write autolocks can be auto-synchronized. >>> Does it >>> not makes sense to allow concurrent and synchronous-write autolocks >>> to also >>> be auto-synchronized? >>> >>> In addition to: >>> >>> ConfigLockLevel.AUTO_SYNCHRONIZED_READ >>> ConfigLockLevel.AUTO_SYNCHRONIZED_WRITE >>> >>> Shouldn't there also be: >>> >>> ConfigLockLevel.AUTO_SYNCHRONIZED_SYNCHRONOUS_WRITE >>> ConfigLockLevel.AUTO_SYNCHRONIZED_CONCURRENT >>> >>> Rational: the concept of automatically introducing a monitor is >>> orthogonal >>> to the type of lock on that monitor. -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
