[concurrency-interest] Lock memory/resource Cost
dholmes at dltech.com.au
Mon Oct 31 16:49:05 EST 2005
> We will investigate the partitioning possibility but I'm afraid that will
> cause more problem than it solve. The input is delivered by some external
> process which does not respect any locality rules. So the treatment could
> not be clustered effectively. (This is why we have choose to lock per
> It seems also difficult to remove some part of the lock. What we
> really want
> is to isolate the treatment of one object for avoiding access to its data
> and update in the same time (which is also not possible with monitor
> read/write lock ...). One other constraint is that on treatment on one
> object could require data from other objects. For avoiding any
> dead lock we are keeping object in an acyclic graph.
If you really can't change the structure then as Doug said built-in locks
seems your best choice. I forgot to make the very important point that Doug
made: which is that built-in locks take no extra space until contended,
while explicit locks consume their full space immediately.
Without knowing more about the system and its architecture there no specific
advice that can be offered. The generic advice is: try to avoid sharing the
objects; use ownership hand-off protocols to restrict access etc.
More information about the Concurrency-interest