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

PlatformMutex::try_lock has different semantics on Windows and Posix

    XMLWordPrintable

Details

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

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved: