[lkml]   [2000]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Wine speedup through kernel module

    Andi Kleen <> wrote:
    > This is far from a single CPU instruction between the test_bit and the
    > set_bit. Even with a single CPU instruction you would need a cmpxchg with
    > retry BTW, to handle the case of multiple CPUs entering the instruction at
    > the same time. The easiest fix is to add a spinlock per mutex.
    > if (test_bit(0,&mutex->wm_state) || mutex->wm_owner!=filp) {
    > ret = 0; /* false */
    > } else {
    > ret = 1;
    > mutex->wm_owner = NULL;
    > set_bit(0,&mutex->wm_state);
    > SignalObject(obj,1);
    > }

    I see what you're getting at... (I was thinking of the mutex grab stage, not
    the release stage).

    Anyway, I though I could get away with it, but on reflection, perhaps
    not... If two threads of the same process try and issue ReleaseMutex()
    simultaneously on one mutex, then theoretically, one should succeed and the
    other fail, but given the above code, you are right... there would be a race.

    Between threads of different "processes" I don't think it'll actually be a
    problem, since mutex theft isn't permitted. I also don't think there'll be a
    conflict between grab and release, since the actual release is the last thing
    done by the ReleaseMutex function, and the actual grab is the first thing done
    by the MutexPoll function.

    But you are right... It should be guarded anyway. Perhaps what I should do is
    to use the owner field as the mutex (NULL is available) and use cmpxchgl to do
    the grab _and_ the release.

    David Howells
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:38    [W:0.021 / U:15.552 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site