OpenOffice Transparent Remote Calls and Non Transparent Behaviour

This document gives a short example about non transparent remote calls in the context of UNO oneway calls.

First of all, for applications which only use synchronous remote calls, the distribution is completely transparent. Except in the case of time transparency, cause remote calls may be slower by factors. The problem all starts when introducing a kind of asynchronous (in UNO terminology ONEWAY) calls.

Just to bring it back to your mind, the definition of UNO oneway calls guarantees the conservation of the call sequence. That means, if you make ten oneway calls followed by a synchronous call, it is guaranteed, that the oneways are all executed before the synchronous call becomes applied.

Here is a short (on the first glance surprising?) example, which shows non transparent behaviour while using oneways:

Code snippet doing some remote drawing:

  void drawSomeText(Color color, Position position) {
      solarmutex->lock();

      outputdevice->setColor(color);
      outputdevice->drawText(position,'this is a sample text');

      solarmutex->release();
  }

  

All methods for the outputdevice are declared oneway to gain some performance advantages.

Imagine two threads executing the code snippet above. It seems, that the operations on the outputdevice are secured by the solarmutex, doesn't it? Just a short thought about the code shows, that it offers some synchronization problems. To make it clear, please have a look at the following interleaved calling sequence:

local

remote

thread1

thread2

dispatcher

Thread1.a

Thread2.a

lock solarmutex

lock solarmutex




snd setColor

wait

queue setColor to 1.a



snd drawText

wait




unlock solarmutex

snd setColor

queue drawText for 1.a




snd drawText





Unlock solarmutex






queue setColor 2.a





queue drawText for 2.a






setColor X

setColor Y




drawText

drawText

Although both threads utilized the solarmutex, the result is somewhat undefined. In the above example, both displayed strings have the some color, which was not intended. The problem is, that the mutex became released even though it was not ensured, that the drawing operations where performed properly. The expected behaviour could have been enforced with two approaches:

Author: KayRamme ($Date: 2001/09/28 15:44:50 $)
Copyright 2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.