g*****g
发帖数: 34805 | 1 http://csourcesearch.net/java/fid960BDFDD3A35D42E6652E79BA3F959A375024F0B.aspx?s=mdef%3Acompute
I found the code like this using Future, which is proposed in
book Java Concurrency in Practice.
It doesn't block if a hit can be found in the cache, it blocks
and there's one and only one thread doing creation, other threads
just wait until the creation completes and gets callback at that time. | s******n
发帖数: 876 | 2 Digging down, this impl involves at least 4 volatile reads in the fastest
case. Per java memory model, a thread is not guaranteed to see updates from
other threads *unless* this thread has some memory barriers like
synchronized, volatile(and others. see
http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html#MemoryVisibility
)
That is why any trick trying to avoid them is doomed to be theoretically incorrect.
An easier to understand impl is to have a separate map storing | g*****g
发帖数: 34805 | 3 FutureTask blocks itself for callback, this is legit.
from
incorrect.
reads
【在 s******n 的大作中提到】
: Digging down, this impl involves at least 4 volatile reads in the fastest
: case. Per java memory model, a thread is not guaranteed to see updates from
: other threads *unless* this thread has some memory barriers like
: synchronized, volatile(and others. see
: http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html#MemoryVisibility
: )
: That is why any trick trying to avoid them is doomed to be theoretically incorrect.
: An easier to understand impl is to have a separate map storing
| s******n
发帖数: 876 | 4 While talking about the best case, i.e. calling get() after value has been
cached, only volatile reads are needed. That does not make it "blocked". "
blocked" means a thread has been waiting to obtain a lock for an extended
period of time.
While volatile are not as expensive as 'synchronzied', they aren't cheap
either. It's far from the ideal of having no penalty at all in retrieving an
already cached value.
【在 g*****g 的大作中提到】
: FutureTask blocks itself for callback, this is legit.
:
: from
: incorrect.
: reads
| g*****g
发帖数: 34805 | 5 Yes, there's a volatile read, but I don't think volatile read
on an int is actually that expensive.
an
【在 s******n 的大作中提到】
: While talking about the best case, i.e. calling get() after value has been
: cached, only volatile reads are needed. That does not make it "blocked". "
: blocked" means a thread has been waiting to obtain a lock for an extended
: period of time.
: While volatile are not as expensive as 'synchronzied', they aren't cheap
: either. It's far from the ideal of having no penalty at all in retrieving an
: already cached value.
| F****n
发帖数: 3271 | 6 To be frankly I am afraid that you got a wrong solution. The problem is the
code here:
Object value = // initialization;
theWrap.putValue(value);
There are no memory barrier between initialization and the writes that set
the value before your synchronized notifyAll(). Image a thread read the
value before notifyAll(). It may detect the value is non
-null, but it actually may be uninitialized.
Your solution is essentially a double check pattern that tries to use notify
to solve the problem, not to
【在 s******n 的大作中提到】
: Digging down, this impl involves at least 4 volatile reads in the fastest
: case. Per java memory model, a thread is not guaranteed to see updates from
: other threads *unless* this thread has some memory barriers like
: synchronized, volatile(and others. see
: http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html#MemoryVisibility
: )
: That is why any trick trying to avoid them is doomed to be theoretically incorrect.
: An easier to understand impl is to have a separate map storing
|
|
