[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: nptl 0.26



> Yes, two releases in one day.  It was another busy day.  I finally
> looked at the read-write locks.  They were almost completely broken.
> using them with some level of stress breaks them.  But this should be a
> thing of the past.  I hopefully got them fixed for good.  This also
> includes to reported base of always calling futex() in the unlock
> functions.  Give it a try.  Other changes include yet more tests.
>

Hi Ulrich.

Thanks for this new implementation of rwlocks

I made this little change : in unlock(), release the mutex before calling
futex_wake()

diff -Nru DESIGN-rwlock.txt.orig DESIGN-rwlock.txt
--- DESIGN-rwlock.txt.orig      Thu Feb 27 09:24:12 2003
+++ DESIGN-rwlock.txt   Thu Feb 27 09:28:45 2003
@@ -96,11 +96,15 @@
   if (!rwlock->readers) {
     if (rwlock->nr_writers_queued) {
       ++rwlock->writer_wakeup;
+      lll_unlock(rwlock->lock);
       futex_wake(&rwlock->writer_wakeup, 1);
+      return;
     } else
       if (rwlock->nr_readers_queued) {
         ++rwlock->readers_wakeup;
+        lll_unlock(rwlock->lock);
         futex_wake(&rwlock->readers_wakeup, MAX_INT);
+        return;
       }
   }


The rationale of this change is to unlock the mutex before calling
futex_wake().
If not, there is a high probability that the kernel preempts the current
thread in favor of the waiting thread(s) in futex_wake().
And the waiting thread hit the locked mutex and recall another futex_wait()
for the mutex.

In my tests, the number of context switches was highly reduced by this
change, botth in UP and SMP configs.


Eric





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]