lkml.org 
[lkml]   [2006]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
    Date

    > Kaz's post clearly interprets the POSIX spec differently from you. The
    > policy can decide *which of the waiting threads* gets the mutex, but the
    > releasing thread is totally out of the picture. For good or bad, the
    > current pthread_mutex_unlock() is not POSIX-compliant. Now then, if
    > we're forced to live with that, for efficiency's sake, that's OK,
    > assuming that valid workarounds exist, such as inserting a sched_yield()
    > after the unlock.

    My thanks to David Hopwood for providing me with the definitive refutation
    of this position. The response is that the as-if rules allows the
    implementation to violate the specification internally provided no compliant
    application could tell the difference.

    When you call 'pthread_mutex_lock', there is no guarantee regarding how
    long it will or might take until you are actually waiting for the mutex. So
    no conforming application can ever tell whether or not it is waiting for the
    mutex or about to wait for the mutex.

    So you cannot write an application that can tell the difference.

    His exact quote is, "It could have been the case that the other threads ran
    more slowly, so that they didn't reach the point of blocking on the mutex
    before the pthread_mutex_unlock()."

    You can find it on comp.programming.threads if you like.

    DS


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-01-26 03:08    [W:0.030 / U:183.592 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site