On Fri, 2005-02-11 at 16:53 -0800, David Graham wrote:
> --- Stephen Colebourne <[EMAIL PROTECTED]> wrote:
>
> > From: "Torsten Curdt" <[EMAIL PROTECTED]>
> > >Regarding the FastHashMap: since the
> > use is more or less discouraged ...why
> > not deprecate it?
> >
> > Because it works on everyth
--- Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> From: "Torsten Curdt" <[EMAIL PROTECTED]>
> >Regarding the FastHashMap: since the
> use is more or less discouraged ...why
> not deprecate it?
>
> Because it works on everything that its been tried on.
It's more like no one has ever noticed i
From: "Torsten Curdt" <[EMAIL PROTECTED]>
Regarding the FastHashMap: since the
use is more or less discouraged ...why
not deprecate it?
Because it works on everything that its been tried on. No-ones ever reported
a bug, its just that with all the double-checked locking theoretical ideas
we have t
Guys,
thanks everyone for the useful input!
Since this part of the code is really(!)
a hotspot I am really careful with any
additional overhead.
...but looks like I need to have a
closer look into the concurrent package
then.
Regarding the FastHashMap: since the
use is more or less discouraged ...w
On Thu, 2005-02-10 at 21:59 -0500, WHIRLYCOTT wrote:
> There's also the original version here:
>
> http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
>
> What does the backport offer that the original util.concurrent lib
> doesn't offer?
The JSR process made some mi
There's also the original version here:
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
What does the backport offer that the original util.concurrent lib
doesn't offer?
phil.
Kevin A. Burton wrote:
WHIRLYCOTT wrote:
I guess this thread should end soon, but while w
WHIRLYCOTT wrote:
I guess this thread should end soon, but while we're still having some
fun ... ;)
ConcurrentHashMap can do concurrent put() operations and concurrent
get() operations... and that's the tricky part.
I just love all that stuff that Doug Lea has done. For those who
haven't look
I guess this thread should end soon, but while we're still having some
fun ... ;)
ConcurrentHashMap can do concurrent put() operations and concurrent
get() operations... and that's the tricky part.
I just love all that stuff that Doug Lea has done. For those who
haven't looked at util.concurr
Torsten Curdt wrote:
Guys, forgive me if this too off topic...
...but I thought it is somehow related to
collections that's why I am bringing it up
here anyway. I bet someone of you will know
Ignore what everyone else says on this list topic. ha.
Use a ReentrantReadWriteLock from JDK 1.5. Th
[collections] provides two Map implementations of interest in this
discussion:
FastHashMap - this map copies the whole map internally every timeput is
called. This avoids most of the synchronization issues, and gets are not
synchronized. However, we do not recommend its use because it _may_ not
Exactly - most books and documentation about resource exclusion about
this make it abundantly clear that synchronized methods shouldn't call
each other for this very reason.
Thanks for adding that point.
phil.
Oliver Zeigermann wrote:
On Thu, 10 Feb 2005 13:09:14 -0500, WHIRLYCOTT <[EMAIL PROTEC
On Thu, 10 Feb 2005 13:09:14 -0500, WHIRLYCOTT <[EMAIL PROTECTED]> wrote:
> 2) synchronize on the containing object's monitor:
>
> ...
> public synchronized whatever(Object arg1) {...}
> public synchronized something() {...}
> ...
>
Blindly doing this can easily l
I spent a whole bunch of time looking into how various
caches/collections handled this issue when I was designing Whirlycache
[1] and the cleanest solution that is available today, as others have
pointed out, is Doug Lea's util.concurrent package.
The high-level explanation of how Doug Lea's Co
This is the save and obvious solution - I agree. But I thought Torsten
wanted something less restrictive where there could be any number of
concurrent reads, but only a single write that also does not allow for
any concurrent reads. This is exactly what a read/write lock does and
is available from
A call to Map.get() may depend on state that can be corrupted by a
concurrent call to Map.put(). You don't know without learning the
implementation details of get(). So, you need to synchronize around both
operations:
synchronized(map) {
Object o = map.get(key);
if (o == null) {
Consider this code...
Object o = map.get(key);
if (o == null) {
synchronized(map) {
map.put(key,new Object());
}
}
99% of the time the "get"s on the map are going
to return an object. That's why I would like
to avoid synchronizing the "get" access.
Now since a "put" might corrupt the
On Thu, 2005-02-10 at 14:20 +0100, Jörg Schaible wrote:
> Torsten Curdt wrote on Thursday, February 10, 2005 2:07 PM:
>
> > Guys, forgive me if this too off topic...
I think this list is a perfectly good place to ask this sort of thing..
> >
> > ...but I thought it is somehow related to
> > col
On Feb 10, 2005, at 8:20 AM, Jörg Schaible wrote:
en get() twice:
Object o = map.get(key);
if (o == null) {
synchronized(map) {
o = map.get(key);
if (o == null) {
map.put(key,new Object());
}
}
}
since 99% of the time it will not enter the block, the second lookup
does not ma
Torsten Curdt wrote on Thursday, February 10, 2005 2:07 PM:
> Guys, forgive me if this too off topic...
>
> ...but I thought it is somehow related to
> collections that's why I am bringing it up
> here anyway. I bet someone of you will know
>
> Consider this code...
>
> Object o = map.get
Guys, forgive me if this too off topic...
...but I thought it is somehow related to
collections that's why I am bringing it up
here anyway. I bet someone of you will know
Consider this code...
Object o = map.get(key);
if (o == null) {
synchronized(map) {
map.put(key,new Object());
20 matches
Mail list logo
