[concurrency-interest] ReadWriteLocks and Conditions

Gregg Wonderly gregg at cytetech.com
Tue Feb 6 09:47:19 EST 2007

Peter Veentjer wrote:
> I don't see how a Future would fit in, maybe you could elaborate on this?

>>>I'm working on a structure called the LendeableReference. This
>>>structure makes it possible to lend a reference to multiple threads
>>>(values are taken from the LendableReference) and after a thread is
>>>done with the reference, it takes it back so that a new reference can
>>>be set. If no reference is available, taking threads block until a
>>>reference is available.

I don't know that I understand the constraints that you want to maintain, but 
based on your comments, it seems to me that the lended reference should access a 
Future.  The user of that object would 'get' the value, and thus block when 
there is no reference available (yet).  The algorithm that would apply in that 
case, is that they 'readers' would always ask a factory for the appropriate 
Future and thus use a relevant new Future when needed.

Here's something that you can pass around, and the users can "get" the value at 
anytime.  You can expand this to do more things about deferring object creation 
beyond the simple setValue() implementation, but this is what I was thinking about.

Maybe you could elaborate on the specifics of what else you need if this is not 

public class LendableReference<T> implements Runnable {
	volatile FutureTask<T> fut;
	volatile T val;
	public LendableReference( T value ) {
		setValue( value );

	public LendableReference( Callable<T> call ) {

	public void setValue( T value ) {
		val = value;
		fut = new FutureTask<T>( this, value );

	public void setValue( Callable<T> call ) {
		fut = new FutureTask<T>( call );

	public T get() {
		return val = fut.get();

	 *  Do nothing to create value.  If you need to do something, override
	 *  run to do the work.
	public void run() {}

More information about the Concurrency-interest mailing list