[haiku-appserver] Re: we need to think, I think...
- From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Wed, 15 Jun 2005 10:20:21 +0300
Hi Stephan,
Stephan Assmus wrote:
> Hi Adi,
>
> I think you make a mistake in the way you approach concurency and
> synchronizing issues.
I know I did a mistake, but I know I'm not totally wrong. :-)
> 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.
Why?
I don't need to lock the data because I _know_ RL's thread will
lock it for me. RL's lock represents the data_lock also.
> You are right about not having to lock the
> RootLayer thread. But you _have_ to lock access to the data.
Sure.
> 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.
I agree. As I told Stefano, "if you really need to lock RL to get
some data, then lock it, BUT don't lock RL to do you clipping calculations
from another thread".
> 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).
I had a look at that code. I think it's a must!
> 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.
I fully agree.
However, there is still a problem, IMO.
We create another "lock", clippingDataLock, a MultiLocker.
Now, the question: should the clipping calculations be done outside RL's
thread(remember my original email) too, or not?
bye,
Adi.
Other related posts:
