[haiku-commits] Re: BRANCH looncraz-github.CAP-dirty [2da99c078677] src/servers/app/drawing/interface/local src/servers/app/drawing src/servers/app data/system/boot
- From: looncraz <looncraz@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Sat, 28 Mar 2015 16:28:32 -0500
On 3/28/2015 15:23, Stephan Aßmus wrote:
Am 28.03.2015 um 00:31 schrieb looncraz-github.CAP-dirty:
From reading the commit, it seems to me like you need to really review
your code to know /exactly/ where you need locking and where you
don't. If you write it's "mostly" serialized, that sounds bad. It
either is /all/ serialized or not. And when there is potential for
deadlocks, then that doesn't mean you don't need locking, it means you
*do* need locking, you just haven't figured out the correct locking
order, or are not making sure you always have the same locking order,
etc.
What I meant by "mostly serialized" was that is was /already/
serialized, but I introduced a condition where it could become
'deserialized' in a few edge cases. I have taken care of those and
everything is working quite well now. (More commits to come).
I don't think you need additional locks. The LockAllWindows() and
LockSingleWindow() in the Desktop should be all you need.
I was thinking so at first, but sadly that wasn't the case. I needed
much more locking. The Desktop isn't the only place which may create
UpdateStreams, they can be created and used within the server itself
(and, with compositing, can be created per window). That means the
HWInterface list needed some locking in addition to needing to provide
locking inside the UpdaeteStream itself. Sad, but true.
I will, of course, be looking for every chance to reduce the amount of
locking, but there is no risk of deadlock the way it is now (I've been
using it straight for a few hours, I'll post a quick video).
But you need to know what code is running in which thread.
I'm always aware of that ;-) I was just thinking a bit too much about
the client-server relationship. If ONLY a client-server relationship
were to exist I would not need to have any HWInterface locking, the
Desktop write lock (LockAllWindows()) would do just fine.
Assuming there is only one Desktop on the HWInterface...
LockSingleWindow() is a MultiLocker::ReadLock(), I've been using
MultiLocker and MRW locks for years, so no worries. I just add locking
very begrudgingly. I almost serialized access without any more locks
(except for UpdateStream), but the performance cost didn't make sense,
so I went away from nearly lock-free to locks-galore. And the
performance benefit was more than I expected.
And don't confuse the type of access on the data. It doesn't matter
whether a thread does only read-access! What matters is which thread
is accessing the data, not the type of access. This is important.
I'm well aware of the requirements for access serialization, but I very
much appreciate the input ;-)
https://github.com/looncraz/Task-C-11/tree/new2
One branch in that project doesn't use any locking ;-)
Here is a quick video of BScreenStream in action. It needs a little
work, particularly with cursor cleanup, but that was expected.
The only thing being copied are the exact areas of the screen that have
changed (obviously), the client has a copy of that region, the client
can forbid an area of the screen (and so can the app_server). I would
like to make it aware of a window to obscure rather than a region, or
even a region of a window... but it really isn't needed ;-) It is
mostly just because I don't want the updates echoed.
http://files.looncraz.net/BScreenStream.mkv
--The loon
Other related posts:
