> > Not having thought this through all the way, I was thinking about an > > integer property that could take one of four values > > "BORROWED" - a ghost in the pool snapshot > > "IDLE" - in the pool, OK to borrow > > "DEAD" - in the pool, marked for eviction > > "VALIDATING" - in the pool, being validated > > If we need to synchronize, similarly to AtomicInteger, we could define > > a synchronized compareAndSet method that borrowObject, returnObject, > > and evict could use to control access. Synchronization would, as you > > point out, cost something, but there should not be much contention for > > these locks. I need to work through the various race conditions, > > though, to convince myself that a volatile field properly managed > > would not suffice. > > Maybe a single volatile boolean could work. I'm not sure either.
Uhm, no it can't work. I see it this way: we have to check from either side, if the object was not concurrently marked by the other side. I.e. in borrowObject one has to check if the object is not currently being validated and only then may mark it as being borrowed. And vice versa for the evict method. Without synchronization or CAS this cannot work, being volatile alone is not enough. Unless I missed something of course and you have a much smarter solution :) greetings Christoph --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
