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

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: