Re: Concurrent bidirectional one-to-many map?
On Mon, 9 May 2011, Sebastian wrote:
Am 09.05.2011 19:28, schrieb Tom Anderson:
On Mon, 9 May 2011, Robert Klemme wrote:
On 8 Mai, 05:51, Tom Anderson <t...@urchin.earth.li> wrote:
On 5/7/2011 2:43 AM, Sebastian wrote:
...
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.
...
This could be solved by standard relationship implementations: Make
workspace a member of Task and synchronize accesses on Task. Example:
https://gist.github.com/962538
By using monitors of Task and Workspace we have quite fine granularity
of locking.
True! The fastest map is no map at all.
If the OP can't modify Task or Workspace, perhaps he could consider
writing wrappers which refer to each other, a TaskWithWorkspace, and
WorkspaceWithTasks (perhaps with better names), and passing those
around rather than plain Tasks and Workspaces.
I can't modify Task, or Workspace, and I won't do much "passing around"
either, as I'm writing a component that will be called remotely (over
RMI). But I suppose I could create a wrapper object for each
Item/Workspace on the first call and look them up in maps indexed on the
Item/Workspace id. Now I wonder if I just have shifted the problem to
these maps?
I don't think you have. The contents of those maps will never change - you
will need to add a new mapping when you first see a new key, but the
mapping will never change (except to be removed), and mappings in the two
maps are independent.
I'll have to brush up on "monitors" and look at the example.
They're pretty simple. A thread can lock something, and later unlock it.
If a thread has already locked something, it can lock it again, but must
make a corresponding number of unlocks to unlock it. If another thread has
already locked something, the thread trying to lock it will wait until
it's unlocked. Acquisition and release of different locks must be nested
(ie lock A, lock B, release A, release B is impossible). While holding a
lock, a thread can wait and notify on an object, which is something you
probably won't need.
For the master maps, though, i'd look at using a ConcurrentMap, which does
not involve locking the whole map. You want to look at the putIfAbsent
method in particular.
You probably will want to use monitors for the WorkspaceWrapper and
TaskWrapper's relationships with each other, though.
tom
--
My dad gave to me a MSX and magazines to read and type programs, mostly
adventure games. I falling in love to the letter soap. -- clrod