[concurrency-interest] Roach motels

Steve Kautz skautz at aonix.com
Wed Nov 16 17:55:03 EST 2005


Jeremy, thanks for that quick reply.

> OTOH, a system cannot, in general, take this:
>
>    synchronized (this) {
>      // stuff
>    }
>    synchronized (that) {
>      // more stuff
>    }
>    synchronized (this) {
>      // even more stuff
>    }
>
> and change it to this:
>
> synchronized (this) {
>    // stuff
>
>    synchronized (that) {
>      // more stuff
>    }
>
>    // even more stuff
> }
>
> because this can introduce deadlock, which may introduce errors in your
> program.


Right. So I think the interesting question is then, in which direction does
the burden of proof go?   For example, if instead of literally having
synchronized(that) we again have something like:

  synchronized (this) {
     // stuff
   }

   otherObject.bar();

   }
   synchronized (this) {
     // even more stuff
   }

how far is the system obligated to look before concluding that bar() will,
or won't, enter a block of the form synchronized(that)?

In particular, in the OSGi example mentioned earlier, method bar()
ultimately invokes callback methods for a list of listeners, some of which
may be synchronized, and which are added/removed dynamically at runtime.  So
no amount of static analysis will show whether or not a call to bar() will
end up invoking "synchronized(that)".   Does the system a) assume that a
method call may end up in synchronized code unless it can prove otherwise,
or does it b) assume it's ok to coalesce the blocks unless it can show that
the call includes something like "synchronized(that)"?

-- Steve K



More information about the Concurrency-interest mailing list