[haiku-commits] Re: haiku: hrev53305 - src/servers/app

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Sun, 28 Jul 2019 13:45:31 +0200

Am 28/07/2019 um 06:19 schrieb waddlesplash:

f9c77b11edcf: app_server: Clean up MultiLocker::IsWriteLocked().
This function was (or at least now is) severely over-engineered:
   it is designed to avoid calling find_thread(NULL) as little
   as possible, and use stack addresses to determine if the current
   thread is the one holding the write lock.
However, this is unneccessary, as find_thread(NULL) has been
   optimized (on x86 and x86_64, at least) to be a single "mov"

I'm not aware of any changes in this regard, do you have a hint for me?

   from thread-local data, with no syscall. So that is probably
   even faster than an integer divide and compare, allowing
   this function to be simplified greatly.

It's a bit shift not an actual divide, and unless you back things up with actual data besides "probably", I really wouldn't throw away any optimizations without digging a bit deeper.

However...

fd97a8c7fe51: app_server: Use a rw_lock instead of 3 (!) semaphores for 
MultiLocker.
Since every HWInterface is a MultiLocker, and every BBitmap requires
   a server-side BitmapHWInterface, this saves 3 semaphores per BBitmap
   instance (as well as a lot of semaphore-related overhead in calling
   the kernel so often.)

... this probably makes this irrelevant, and is really a nice and welcomed change! Our userland locks are greatly underused, and should become public API.

I remember MultiLocker had some strange functionality, but maybe that was only for debugging purposes.

Bye,
   Axel.

Other related posts:

  1. Home
  2. haiku-commits
  3. Archive
  4. 07-2019