[concurrency-interest] Fwd: ReadWriteLocks and Conditions

Tim Peierls tim at peierls.net
Wed Feb 7 11:15:30 EST 2007


I'm saying the signature of your LendableReference looks like a resource
pool. The restriction to pool size of 1 doesn't affect the interface, so why
limit it unnecessarily at that level?

    interface ResourcePool<T> {
        void release(T resource);
        T acquire() throws InterruptedException;
        T tryAcquire();
        T tryAcquire(long timeout, TimeUnit unit) throws
InterruptedException;
    }

    abstract class AbstractResourcePool<T> implements ResourcePool<T> {
        private final Semaphore semaphore;
        protected AbstractResourcePool(int poolSize) {
            this.semaphore = new Semaphore(poolSize);
        }
        protected abstract T allocateResource();
        protected abstract void deallocateResource(T resource);
        ...
        public void release(T resource) {
            deallocateResource(resource);
            semaphore.release();
        }
        public T acquire() throws InterruptedException {
            semaphore.acquire();
            return allocateResource();
        }
        public T tryAcquire() {
             return semaphore.tryAcquire() ? allocateResource() : null;
        }
        public T tryAcquire(long timeout, TimeUnit unit) throws
InterruptedException {
            return semaphore.tryAcquire(timeout, unit) ? allocateResource()
: null;
        }
     }

--tim

On 2/7/07, Peter Veentjer <alarmnummer at gmail.com > wrote:
>
> Hi Tim,
>
> I haven't found another synchronization stone that fitted my needs.
> Can you point me to the work others have done? Something I want to
> prevent is 'modifying' other synchronization structures so they behave
> the way I want. Concurrency control is complex, and that is why I
> prefer using synchronization structures that make clear what they are
> doing.
>
> I'm going to look at simplifying the design by using a semaphore.
> Thank you for the suggestion.
>
>
>
> On 2/6/07, Tim Peierls < tim at peierls.net> wrote:
> > LendableReference is essentially a resource pool of size 1. Other folks
> have
> > done a lot of work on the general case -- why not take advantage of
> that?
> >
> >  Or if you really want to roll your own, consider using Semaphores, as
> > described in section 5.5.3 of Java Concurrency in Practice.
> >
> >  --tim
> >
> >
> > On 2/6/07, Peter Veentjer < alarmnummer at gmail.com> wrote:
> >
> > > Example usage:
> > >
> > > while(true){
> > >         Runnable task = lendableRef.take();
> > >         try{
> > >                 task.execute();
> > >         }finally{
> > >                 lendableRef.takeBack(task);
> > >         }
> > > }
> > >
> > > By placing a Runnable in the lendableRef, the task is being executed.
> > > By removing the Runnable from the lendableRef (so setting a null
> > > value) the take blocks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070207/e54095c9/attachment.html 


More information about the Concurrency-interest mailing list