Re: Concurrent bidirectional one-to-many map?
Sebastian wrote:
schrieb markspace:
Sebastian wrote:
Does anyone know of a concurrent bidirectional one-to-many
map implementation?
By bidirectional I mean that I can lookup keys by values, by
You want Apache Commons Collections, BidiMap, perhaps.
one-to-many I mean that the value end of the map is a list or
set, and by concurrent I mean that I do not need to synchronize
externally and get performance comparable to that of
java.util.concurrent.ConcurrentHashMap in both directions.
If this beast doesn't exist, how would I go about inventing it?
I must say that I am by no means any sort of concurrency guru...
Can you just put both keys and values in as the key? Something like:
Map<Key,Key> myMap =...
Thanks for the idea. I do not yet see how to deal with the
one-to-many aspect of my problem.
To give an example, I'm trying to solve a problem like this:
Associate tasks with workspaces, where a workspace may hold many
tasks,but a task may be associate with at most one workspace.
Idea:
private ConcurrentMap<Item, Workspace> wsMap =
new ConcurrentHashMap<Item, Workspace>();
public boolean isAssigned( Item item ) {
return wsMap.containsKey( item );
}
public void assign( Item item, Workspace ws ) {
wsMap.putIfAbsent( item, ws );
if( !ws.equals( wsMap.get( item) ) ) {
throw new NotAssignableException();
}
}
Now I want to be able to close a workspace, releasing all tasks
to be assignable again to other workspaces.
public void closeWorkspace( Workspace ws ) {
// how do this efficiently? iterate over all
// entries (holding a write lock) and remove it
// when the value equals ws?
}
You're closing workspaces, so presumably you're at the end of some sort of
session. How efficient does this have to be? What else is using this
'Workspace' instance at the same time? If something else is trying to access
the same 'Workspace' instance at the same time, isn't that already too bad
because you're closing the 'Workspace'? SO - just hold the lock (one you use
explicitly and for all operations on the same instance) until the method is done.
You use the work "efficiently" as if it means anything here, but you have not
thought about that meaning in context. On the face of it, it looks like you
need nothing at all to do with "efficiency".
I'm not so sure that 'ConcurrentMap' is the way to go here. You need to use
explicit locks based on what I see here.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg