[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: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Sat, 28 Mar 2015 21:23:50 +0100
Am 28.03.2015 um 00:31 schrieb looncraz-github.CAP-dirty:
added 1 changeset to branch 'refs/remotes/looncraz-github/CAP-dirty'
old head: 70f5d8fd08ae5b241a14129ad4b4b670e624dbfe
new head: 2da99c078677233b27c6693ca65908d10988c8ad
overview: https://github.com/looncraz/haiku/compare/70f5d8fd08ae...2da99c078677
----------------------------------------------------------------------------
2da99c078677: Get rid of spurios locks
Access is mostly serialized and locking just adds overhead and the
potential for deadlocks, so getting rid of it wherever possible.
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.
I don't think you need additional locks. The LockAllWindows() and
LockSingleWindow() in the Desktop should be all you need. But you need
to know what code is running in which thread. If you have code that
always runs in a ServerWindow thread and /never/ uses data that the
Desktop, event loop, or a ServerApp thread also access, then you don't
need locking. If it /can/ be accessed by any of those threads, then you
*do* need locking: The ServerWindow thread would call LockSingleWindow()
and the other threads *always* need to call LockAllWindows(). The
difference is why it works in the first place and without this
distinction, there isn't actually any locking. A ServerWindow thread
also needs to call LockAllWindows() in those cases where it reads or
modifies data structures that are shared across itself, other
ServerWindows, or the Desktop etc. A ServerWindow can only then call
LockSingleWindow() when it reads or modifies data structures that other
threads may read/modifiy only within LockAllWindows() protected sections.
It's a bit complicated at first. But LockSingleWindow() is only for
ServerWindow threads and means these ServerWindow threads can run in
parallel, but block any other threads from running through the same
section of code (or read/modify the same data). And LockAllWindows() is
needed by any other thread when accessing data that is also accessed by
a ServerWindow thread.
Because it is so important, I'll explain it again looking from the data:
1) Data private to a ServerWindow and *never*, not even indirectly,
accessed by any other thread: No locking necessary.
2) Data belongs to ServerWindow, but may be accessed by the Desktop or
ServerApp thread: ServerWindow thread uses LockSingleWindow(), the other
threads use LockAllWindows().
3) Data accessed by different ServerWindow threads: Always use
LockAllWindows().
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.
Best regards,
-Stephan
Other related posts:
