Yep - that's the general impression out there - that concurrent/synch-write autolocks can be auto-synchronized the same way.
Also with regards to distributed monitors obtained via an instance of a shared ReentrantReadWriteLock: a> We also need to make clear (that's more of a DOCs issue thought) that such a distributed lock is in no way impacted by what you autolock on...it simply depends on whether the ReentrantReadWriteLock instance is shared or not. b> But it would be sweet if we could inject a ReentrantReadWriteLock.writeLock().lock()/unlock() also the same way (as we inject autosynchronization)...so you can get more surgical around where u introduce the distributed monitor. Tim Eck wrote: > Seems reasonable to me. Anyone know if there is a reason why it isn't > already that way? > > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:tc-dev- >> [EMAIL PROTECTED] On Behalf Of Gary Keim >> Sent: Thursday, September 06, 2007 5:59 PM >> To: [email protected] >> Subject: [tc-dev] auto-synchronized autlocks >> >> 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. >> >> _______________________________________________ >> tc-dev mailing list >> [email protected] >> http://lists.terracotta.org/mailman/listinfo/tc-dev >> > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
