[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,
-Stephan
- Follow-Ups:
- [haiku-appserver] Re: we need to think, I think...
- From: Adi Oanca
- References:
- [haiku-appserver] we need to think, I think...
- From: Adi Oanca
Other related posts:
- » [haiku-appserver] we need to think, I think...
- » [haiku-appserver] Re: we need to think, I think...
- » [haiku-appserver] Re: we need to think, I think...
- » [haiku-appserver] Re: we need to think, I think...
- » [haiku-appserver] Re: we need to think, I think...
- » [haiku-appserver] Re: we need to think, I think...
- » [haiku-appserver] Re: we need to think, I think...
- » [haiku-appserver] Re: we need to think, I think...
- » [haiku-appserver] Re: we need to think, I think...
- [haiku-appserver] Re: we need to think, I think...
- From: Adi Oanca
- [haiku-appserver] we need to think, I think...
- From: Adi Oanca