[concurrency-interest] Lock memory/resource Cost

David Holmes dholmes at dltech.com.au
Mon Oct 31 16:49:05 EST 2005


Thierry,

> 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
> object)
>
>
> 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.

Good luck.

David Holmes



More information about the Concurrency-interest mailing list