[haiku-bugs] Re: [Haiku] #8007: [app_server] fully unresponsive when resizing window of big textfile
- From: "jua" <trac@xxxxxxxxxxxx>
- Date: Sun, 08 Sep 2013 16:58:47 -0000
#8007: [app_server] fully unresponsive when resizing window of big textfile
-----------------------------+----------------------------
Reporter: ttcoder | Owner: axeld
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: System/Kernel | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking: 7882, 8136
Has a Patch: 1 | Platform: All
-----------------------------+----------------------------
Comment (by jua):
Replying to [comment:85 bonefish]:
> Since `sPortsLock` doesn't only protect the ports hash table but also
`Team::port_list` and `Port::owner` only using a lock-free data structure
won't suffice. Maybe you addressed that as well?
In the lockfree port list version, I left those protected by a mutex
currently... so this mutex is still locked on e.g. port creation or
deletion. By far most operations on the port list are lookups though, and
those need no lock anymore.
> That requires making `Port` a `BReferenceable`, so `get_locked_port()`
needs to hold `sPortsLock` only while incrementing the reference.
Heh, in the lockfree version that is already the case :) Since any number
of threads can concurrently lookup/insert/delete on it, and when removing
an element you can never know who still has a reference in their hands,
the ports had to be become refcounted (using KernelReferenceable though to
be safe - would BReferenceable be enough?). So in parts I can reuse
that...
The other suggestions I will look into. Would be interesting to compare a
version with RW-locks versus the lockfree one (although lock-free has no
lock wait times, it comes with the price of a higher overhead per
operation, i.e. it is only an advantage when concurrency is high).
--
Ticket URL: <http://dev.haiku-os.org/ticket/8007#comment:86>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
