Gabe Yoder <gyoder@xxxxxxxxxxx> wrote: > > ATM invalidating and drawing is done from almost every thread in > > app_server. IMHO this is not that good as we do need a lot of > > locking, and > > code flow is hard to follow. I propose we have methods like > > ::Invalidate, > > ::Redraw, which if executed from another thread than this > > drawing_thread, > > automatically send port messages for the requested action. Having it communicating via ports could be more expensive than locking. It all depends on how long a drawing operation holds the lock, of course. > Reducing the amount of required locking is probably a good thing, > although I > am not totally clear on what you are proposing as a replacement to > the > current system (it might help if I paid more attention to the current > implementation of the desktop code). Could you elborate more on the > system > that you have in mind? > One advantage that I can see to having a single drawing thread that > receive a > bunch of messages is that it could allow us to prevent starvation for > access > to the DisplayDriver. If I am not mistaken, under the current system > with > all of the threads making calls to the DisplayDriver, we could end up > in a > situation where a thread or group of threads keeps hammering on the > DisplayDriver, and another thread never manages to get the lock > because > everybody else manages to cut ahead in line. If we have a single > thread > responsible for drawing, we can just fire off the message and build > up a > queue of things to do (assuming that there isn't some risk of > starvation in > passing the messages). Of course, this whole argument is meaningless > if > there is some sort of FIFO mechanism on the Lock. If you are just using semaphores, then yes, there is such a mechanism: the lock is granted in the exact same order acquire_sem() has been called. You would have the starvation problem everywhere if it would have been done differently. Bye, Axel.