lkml.org 
[lkml]   [2006]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
    David Schwartz wrote:
    >> 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.

    Not true. The code for the relinquishing thread could indeed tell the difference.

    -ml
    -
    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:51    [W:0.029 / U:152.008 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site