You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Yang ZHONG <le...@gmail.com> on 2006/12/21 00:27:48 UTC

[Java] Trade off dirty read for Map performance

http://issues.apache.org/jira/browse/TUSCANY-1006
brings up a Map concurrency issue.

We probably can support concurrent Map and trade off dirty read for Map
performance.
What do you think please?

It improves User Experience if we support concurrent Map in ChangeSummry for
instance.
A complete thread-safe Map can synchronize reads on ReadWriteLock#readLock()
and synchronize writes on ReadWriteLock#writeLock().
Unfortunately ReadWriteLock isn't handy until JDK 1.5.
Not sure we want to introduce additional library dependency when we're still
on 1.4.
Synchronizing all reads and writes on single lock causes bad performance, as
Ron has pointed out.

Synchronizing only writes may cause reads access invalid memory.
This's the code snippet implementing HashMap#get:
        int i = indexFor(hash, this.table.length);
        Entry e = this.table[i];
The index i may not be valid any longer since a concurrent put may change
this.table to a different memory.
A simple change may make it thread-safer:
        Entry tab = table;
        int i = indexFor(hash, tab.length);
        Entry e = tab[i];
However, the read may be dirty.

Dirty reads might be fine to some users, especially with big performance
gain.
I had implemented a ThreadSaferMap similar to above change several years
ago in a product,
and no problem has been reported so far.
Do we also want to trade off dirty read for Map performance?

-- 

Yang ZHONG