avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harmeet Bedi" <hb...@yahoo.com>
Subject Re: [GUMP] Build Failure - James and Lock related changes
Date Mon, 09 Apr 2001 18:21:45 GMT

----- Original Message -----
From: "Berin Loritsch" <bloritsch@apache.org>
> 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.

I did read it, but did had no cycles to follow up or think about the impact.
I have for now added the old Avalon Lock Classes to James. This is a stopgap
measure otherwise James would suffer from the same problems you found in
Cocoon. James does seem to rely on the previous Lock API. Maybe the same API
can be built in some other object using the new Lock implementation.

>
> 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.

Names don't matter that much however if Avalon can use or reuse a standard
package, than the same names should be mentained. Well my vote is not
important and in any case it is 0.


>
> > 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.

I make lots of multithreading mistakes. Would prefer to rely on a well
tested, widely reviewed and fast library. But that is sometimes a chicken
and egg problem. Not sure if there is a need for a new implementation, but
if there is, good to get it done and available as part of Avalon. :-)

Harmeet


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


---------------------------------------------------------------------
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