At 04:43 PM 6/25/2003 +0200, Ceki Gülcü wrote:
For the PluginRegistry, it seems to me that the third condition is
not. If that is true, then there is no gain in using this type of
fancy lock.
I had meant to write "is not met" and not just "is not". The corrected
version reads:
For the PluginRegistr
At 10:29 AM 6/24/2003 -0700, Mark Womack wrote:
Ceki,
I made the changes in PluginRegistry, but I still need to test it out. I
like the use of ReaderWriterLock. It is going to be better than the
synchronized blocks I had before.
A ReaderWriterLock can be used to protect a resource if all of the
:32 AM
> To: Log4J Developers List
> Subject: RE: ReadWriterLock usage
>
>
>
> Howdy,
>
> >I'm surprised that
> >a concurrency library is not part of Commons. Or maybe I just missed
> it?
>
> Commons-concurrency would be fairly useless, considering the
as well.
-Mark
> -Original Message-
> From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 24, 2003 10:32 AM
> To: Log4J Developers List
> Subject: RE: ReadWriterLock usage
>
>
>
> Howdy,
>
> >I'm surprised that
> >a concurrenc
Ceki Gülcü wrote:
At 11:50 AM 6/24/2003 -0400, Berin Loritch wrote:
:) I guess you are calling me lazy ;P (Like all programmers)
Even if most programmers wear a badge of laziness with pride, I really
did not mean to imply any deficiency on your part. I am sorry if it
came out that way.
I neve
At 11:50 AM 6/24/2003 -0400, Berin Loritch wrote:
Ceki Gülcü wrote:
At 09:16 AM 6/24/2003 -0400, Berin Loritch wrote:
Ceki Gülcü wrote:
In my experience, and I have only been doing high volume server apps for
about
four years now, you can never rely on theory. Always err on the side of
caution
Howdy,
>I'm surprised that
>a concurrency library is not part of Commons. Or maybe I just missed
it?
Commons-concurrency would be fairly useless, considering the excellence
of Doug Lea's concurrency library (which has been around for a long time
and works on older JDKs as well).
Yoav Shapira
lcü [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 24, 2003 6:04 AM
> To: Log4J Developers List
> Subject: Re: ReadWriterLock usage
>
>
> At 09:16 PM 6/23/2003 -0700, you wrote:
> >I was looking at the usage of the ReadWriterLock class the
> Category code
> >as a
Ceki Gülcü wrote:
At 09:16 AM 6/24/2003 -0400, Berin Loritch wrote:
Ceki Gülcü wrote:
In my experience, and I have only been doing high volume server apps
for about
four years now, you can never rely on theory. Always err on the side of
caution.
The core of log4j is quite small. So what appl
At 09:16 AM 6/24/2003 -0400, Berin Loritch wrote:
Ceki Gülcü wrote:
In my experience, and I have only been doing high volume server apps for about
four years now, you can never rely on theory. Always err on the side of
caution.
The core of log4j is quite small. So what applies for large pieces of
Ceki Gülcü wrote:
At 09:16 PM 6/23/2003 -0700, you wrote:
Hello Mark,
Constraining all lock operations to try/finally block is certainly
safe. In the Category class where new ReaderWriterLock code was added,
there is one occasion where a try/finally block is used, namely within
the callAppenders
At 08:28 AM 6/24/2003 -0400, you wrote:
Mark Womack wrote:
I was looking at the usage of the ReadWriterLock class the Category code
as an example for my similar modification to the PluginRegistry.
Shouldn't all the releaseWriteLock() and releaseReadLock() calls be
contained in finally blocks? U
At 09:16 PM 6/23/2003 -0700, you wrote:
I was looking at the usage of the ReadWriterLock class the Category code
as an example for my similar modification to the PluginRegistry.
Shouldn't all the releaseWriteLock() and releaseReadLock() calls be
contained in finally blocks? Unless we are absolu
Berin Loritsch wrote:
Mark Womack wrote:
I was looking at the usage of the ReadWriterLock class the Category
code as an example for my similar modification to the PluginRegistry.
Shouldn't all the releaseWriteLock() and releaseReadLock() calls be
contained in finally blocks? Unless we are ab
Mark Womack wrote:
I was looking at the usage of the ReadWriterLock class the Category code
as an example for my similar modification to the PluginRegistry.
Shouldn't all the releaseWriteLock() and releaseReadLock() calls be
contained in finally blocks? Unless we are absolutely sure that an
e
+1,
you probably never be sure that an exception is not thrown. Good protective
style.
-Original Message-From: Mark Womack
[mailto:[EMAIL PROTECTED]Sent: Tuesday, 24 June 2003 2:16
PMTo: Log4J Developers ListSubject: ReadWriterLock
usage
I was looking at the usage of the
16 matches
Mail list logo
