[haiku-appserver] Re: we need to think, I think...

  • From: "Stephan Assmus" <superstippi@xxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Mon, 13 Jun 2005 17:59:36 +0200 CEST

Hi Adi,

I think you make a mistake in the way you approach concurency and 
synchronizing issues. The RootLayer thread manages data. This data is 
accessed from other threads as well, such as the ServerWindow threads. 
One example being the clipping regions that are calculated in the 
RootLayer thread. You seem to think that when you send the RootLayer 
thread a message to do the calculation, you don't need to lock the 
data, but this is wrong. You are right about not having to lock the 
RootLayer thread. But you _have_ to lock access to the data. A 
ServerWindow thread might access the clipping info at any time, even if 
it only reads the data. It might happen right in the middle of the 
RootLayer thread recalculating clipping info. So locking _must_ happen, 
no matter how the RootLayer thread was told to do its thing.

The interesting bit is that each of the ServerWindow threads is only 
reading the information. This means that it would be nice to allow all 
ServerWindow threads to access the information at the same time. So one 
ServerWindow thread should not prevent another ServerWindow thread from 
reading the same info. This design problem is commonly solved by read/
write locking. It means that there can be multiple readers _or_ one 
writer at the same time. So as long as there are readers in the queue 
for getting the lock, the writer is blocked from acces, until there are 
no more readers. The readers are only blocked as long as there is 
someone having write access. They don't block because someone else has 
read access.

We have good and proven implementations of this MultiLocker code. There 
is the one from the sample code, which originates from the R5 
app_server and is appearently tuned for perfomance. Then there is Axels 
implementation and YellowBites has an implementation as well from Ingo, 
which is very feature rich. It even handles nested locking with 
timeouts (maybe Axels does this too).

Finally, I think incorporating this locking scheme to protect the layer 
tree and clipping info into what we currently have, would be very easy. 
It does not involve changing lots of code. Please consider that this 
step does not have anything to do with speed concerns, it is a 
requirement. We have no other options.

Best regards,

Other related posts: