avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [GUMP] Build Failure - James and Lock related changes
Date Mon, 09 Apr 2001 12:34:54 GMT
Harmeet Bedi wrote:
> 
> The build failure seems to be because of recent changes in the Lock
> API/Implemenation. Not sure how to fix this.
> 
> I don't really know why the lock API changed. The earlier one seemed be in
> use, and a parts of James rely on it. For example see the attached mail.

The Lock implementation DID NOT WORK in its previous form.  For some reason,
when we had one Lock object handle the locks for multiple objects, the Lock
would not prevent access.  This caused some concurrency issues in the Pool
implementations.  The API was changed to lock() and unlock() with no parameters.
canLock() and isLocked() were not implemented, as I didn't think they were
truly useful.  They can be added back in, but without ANY params.  I was
focusing on getting something that really worked.

I did post an email about this to the Avalon Dev list when I committed it,
but it looks like noone read it.

> Also comparing the new Lock implementation from util.concurrent's Mutex, I
> realized. that if there is an InterruptedException thrown in the Lock method
> the other waiting to acquire threads are not notified. There seems to be one
> more problem. the attached comparison could be useful.
> 
> <acquire> method of util.concurrent's Mutex.
> ----------------------------------------------------------
>   public void acquire() throws InterruptedException {
>     if (Thread.interrupted()) throw new InterruptedException();
>     synchronized(this) {
>       try {
>         while (inuse_) wait();
>         inuse_ = true;
>       }
>       catch (InterruptedException ex) {
>         notify();
>         throw ex;
>       }
>     }
>   }
> ------------------------------------------

If we want to adopt the aquire()/release() names, it's nothing but a name
thing.  The contents change with the InterruptedException is excellent,
and can help prevent some deadlocks.  I will incorporate that.

But lets vote on the "Class : Method" names:

1) Mutex : aquire()/release()
2) Lock : lock()/unlock()

I have no qualms or preferences about either--I just want this thing to
work properly.

> I think one should reuse a solid concurrency management library if it is
> available. I think one should consider Doug Lea's package as a reasonable
> and stable candidate. Anyway not sure how to fix the James build in a safe
> manner, hope someone knows how to.

OK.  I was working on what was already in Avalon.  If there is a solid
concurrency management library available with a compatible license, then
go for it.  Note, we did have someone express interest in donating or
developing a number of classes that would fill this need.

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message