2

Considering the following extended definition of reentrancy by POSIX :

In POSIX.1c, a "reentrant function" is defined as a "function whose effect, when called by two or more threads, is guaranteed to be as if the threads each executed the function one after another in an undefined order, even if the actual execution is interleaved" (ISO/IEC 9945:1-1996, §2.2.2).

Source: http://www.unix.org/whitepapers/reentrant.html

Since a thread-safe function does serialize concurrent executions and thus "the threads each execute the function one after another in an undefined order, even if the actual execution is interleaved" too, does it imply that a thread-safe function is reentrant (only considering POSIX definition)?

Julio Guerra
  • 5,523
  • 9
  • 51
  • 75
  • See http://stackoverflow.com/a/2799288/2235132 – devnull May 31 '13 at 07:34
  • @devnull no, it does not consider POSIX definition – Julio Guerra May 31 '13 at 07:35
  • 1
    I think its the keyword 'interleaved' which makes the difference; the thread safe part is sequential or have to be and not really interleaved. Just a guess... – vpram86 May 31 '13 at 08:27
  • 1
    I'd say POSIX-wise, reentrant implies thread-safe, but not necessarily the other way around. However the only examples I know come from the Windows implementation of non-reentrant C functions like `strtok()`: Their implementation is thread-safe because it uses thread-local storage, but it's not reentrant. I have no idea whether the POSIX versions of these functions (or some implementations thereof) are thread-safe. – Medinoc May 31 '13 at 08:58
  • 1
    possible duplicate of [What exactly is a reentrant function?](http://stackoverflow.com/questions/2799023/what-exactly-is-a-reentrant-function) – Ansgar Wiechers Jun 01 '13 at 19:50
  • 1
    @AnsgarWiechers does this question talk about POSIX.1c definition? no... – Julio Guerra Jun 03 '13 at 06:22

3 Answers3

3

No, a thread-safe function is not necessarily reentrant.

Consider e.g. a function with some internal state that is protected by a mutex, thus making it thread-safe. However, if that function is called, er, re-entrantly from the same thread, a deadlock occurs. A common example of such a function is malloc(); malloc is thread-safe but not reentrant which why you should not call malloc from within a signal handler, for instance.

janneb
  • 36,249
  • 2
  • 81
  • 97
1

Thread-safe code does not need to serialize concurrent executions, because of this I would say that thread-safe function does not need to be reentrant according to the POSIX definition that you cited.

Consider a following example. You have two thread safe functions:

void inc_count(struct counter* cnt);
int get_count(struct counter* cnt);

You can use these two to define another thread safe function:

inc inc_and_get_count(struct counter* cnt) {
   inc_count(cnt);
   return get_count(cnt);
}

Contract of such function does not guarantee that returned value will be equal to the value that inc_count() set, it can be larger, but the function is still thread safe.

But it is not reentrant according to the definition, two calls to the function from two different threads can return the same value, which would never be the case if executions were serialized.

Jan Wrobel
  • 6,969
  • 3
  • 37
  • 53
1

No. Reentrancy and thread-safety are orthogonal properties of a function. The POSIX.1c definition of a reentrant function does not imply thread-safety since a function may be reentrant, thread-safe, both or neither. A reentrant function guarantees only that invocations do not interfere with each other by modifying state that other invocations depend on, not that those invocations are necessarily thread-safe.

Amilcar
  • 21
  • 1