[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

 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: