Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8256383

PlatformMutex::try_lock has different semantics on Windows and Posix

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P4 P4
    • 16
    • 13, 15, 16
    • hotspot
    • None
    • b07
    • 13
    • b26
    • windows

      In a situation where the lock is already held by the thread calling try_lock, the two implementations have the opposite semantics.

      Windows:
      inline bool os::PlatformMutex::try_lock() {
        return TryEnterCriticalSection(&_mutex);
      }

      "If the critical section is successfully entered or the current thread already owns the critical section, the return value is nonzero.

      If another thread already owns the critical section, the return value is zero."

      Posix:

      inline bool os::PlatformMutex::try_lock() {
        int status = pthread_mutex_trylock(mutex());
        assert_status(status == 0 || status == EBUSY, status, "mutex_trylock");
        return status == 0;
      }

      "The pthread_mutex_trylock() function shall be equivalent to pthread_mutex_lock(), except that if the mutex object referenced by mutex is currently locked (by any thread, including the current thread), the call shall return immediately."

      and:
      "[EDEADLK]
          A deadlock condition was detected or the current thread already owns the mutex."

      This difference propagates up to the Mutex::try_lock implementation.

            dholmes David Holmes
            stefank Stefan Karlsson
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: