Defining "thread-safety" and maybe something that isn't "thread-safety"

Every time I try to lookup the definition of "thread-safe" I get told that a routine is thread-safe if it can be called by more than 1 thread at the same time. (They also seem to be very Java-oriented, in which this definition might be sufficient) But this seams to mean if that if a function is not thread-safe, then it's ok if that function only gets called by one thread. Or does it?

Suppose foo() is declared not thread-safe because it calls the POSIX function asctime(), which returns a pointer to static space, rather than its reentrant counterpart, asctime_r(). One might think that it's ok to have multiple threads in one's program, as long as foo() calls are confined to just 1 thread, but suppose another thread calls asctime()? It seems to me that if something is not thread-safe then that kills your freedom to use any other code that isn't thread-safe either.

I don't know if I'm using "thread-safe" here properly, but I've definitely hit upon a problem of concurrency that deserves to have a name. So what is it?

Calling something which is not thread safe is OK, so long as you guarantee that it can only be called by 1 thread at once.

You can do this in two ways
- only call it from one thread
- create an access function which wraps a mutex around the call to the unsafe function.

Why would you want to introduce bugs in your code by using something which is not thread-safe in a multithreaded environment?

Quote:

---

Originally Posted by Salem

Calling something which is not thread safe is OK, so long as you guarantee that it can only be called by 1 thread at once.

You can do this in two ways
- only call it from one thread

---

This would explain why you can do such a thing unscathed when using a threaded API, without programming any threads of your own. Maybe the OP is being paranoid?

Yes, you can think of "thread safe" as being an awful lot like "const." A const function can only invoke other const functions, and a thread-safe function can only invoke other thread-safe functions.

A function which is not natively thread-safe can be turned into a thread-safe version by wrapping it in a function which does locking to enforce serial access. But that should be a last resort.

EDIT: In the instance of asctime(), just wrapping with a lock is not sufficient, because it isn't clear when the pointer to static data becomes stale. You would have to do something else, like wrap with a lock AND make a copy of the result before unlocking the lock, then returning the copy.

None of these responses directly address the issue.

Salem just gives the popular definition of "thread-safe" which does not address this issue of concurrency that I'm focusing on.

PING seems to be saying that using code that isn't thread safe means that threads are out of the question, but doesn't come out and say it.

MK27: I'm definitely not paranoid, since I've clearly hit on a problem of concurrency.

I need to know the correct definition of "thread-safe". If that is Salem's definition, then there's this other issue of concurrency that no one seems to address. Go back and read the OP.

Quote:

---

Originally Posted by Angus

I need to know the correct definition of "thread-safe". If that is Salem's definition, then there's this other issue of concurrency that no one seems to address. Go back and read the OP.

---

The definition of thread safe is "safe to call from multiple threads." I'm not sure what else you are looking for. Another term with a similar meaning is "reentrant" which simply means that a region of code can safely be activated multiple times. That's more encompassing than "thread safe" because it also implies that the function is recursion-safe.

Quote:

---

Originally Posted by brewbuck

The definition of thread safe is "safe to call from multiple threads." I'm not sure what else you are looking for. Another term with a similar meaning is "reentrant" which simply means that a region of code can safely be activated multiple times. That's more encompassing than "thread safe" because it also implies that the function is recursion-safe.

---

Ok, so what if we have

Code:

---

char *foo() {
    return asctime();//not a thread-safe function
}
char *goo() {
    return ascitime();//still not thread-safe
}

int main() {
    StartThread(Thread);
    fprintf(file0, "goo(): %s\n", goo());
...
}

void Thread() {
    fprintf(file1, "foo(): %s\n", foo());
}

---

Both foo() and goo() were labeled as not thread-safe, so we were careful not to have one of them called in 2 threads, but both call the same function that isn't thread-safe, so we have a concurrency problem, even though we've respected "thread-safety".

Another important ramification is if you have 2 3rd party libraries, and both are not thread-safe, you can't trust them in a multi-threaded program, even if you confine all your calls to each library to its own thread.

Quote:

---

Originally Posted by Angus

Both foo() and goo() were labeled as not thread-safe, so we were careful not to have one of them called in 2 threads, but both call the same function that isn't thread-safe, so we have a concurrency problem, even though we've respected "thread-safety".

---

Mind explaining the concurrency problem? It seems to me there is no such problem since the pointer returned by the first call to asctime() is used and done with before the next call to asctime(), unless I understand the code wrongly.

EDIT:
Nevermind, I suspect it is merely due to my lack of familiarity with threads.

Quote:

---

Originally Posted by Angus

Both foo() and goo() were labeled as not thread-safe, so we were careful not to have one of them called in 2 threads, but both call the same function that isn't thread-safe, so we have a concurrency problem, even though we've respected "thread-safety".

---

No, it does not respect thread safety. Both foo() and goo() call a non-thread-safe function and are therefore not thread safe by definition. Thread safety does not just include the code which is verbatim in the function in question, but any code called directly or indirectly by that function.

Quote:

---

Another important ramification is if you have 2 3rd party libraries, and both are not thread-safe, you can't trust them in a multi-threaded program, even if you confine all your calls to each library to its own thread.

---

Correct. Even a huge lock will not help, because you can't know whether the library is caching some piece of data (for instance the return value of asctime() ) because it assumes it is the only thread of execution. Such libraries are mostly useless in modern programming.

That said, it doesn't have to be hard to write a thread-safe library although sometimes it can be.

Quote:

---

Originally Posted by brewbuck

No, it does not respect thread safety. Both foo() and goo() call a non-thread-safe function and are therefore not thread safe by definition. Thread safety does not just include the code which is verbatim in the function in question, but any code called directly or indirectly by that function.

---

It does by every definition of thread-safe that's been thrown at me. Foo() cannot be called again until it is finished, and the same criteria applies to goo(). If the definition were extended to imply that nothing else that isn't thread-safe can be trusted to run while foo() and goo() are running, that would be different, but that's not what I've been hearing.

Quote:

---

Originally Posted by brewbuck

That said, it doesn't have to be hard to write a thread-safe library although sometimes it can be.

---

It's not always that simple. This came up because I have these 2 close source libraries that I want to run concurrently. Unfortunately, neither appear to be thread-safe by any definition, so I've had to chuck all my threading code and go for a multi-process solution. It wouldn't make sense to put any reentrant wrapper around the library calls, since that would in effect make execution serial.

Quote:

---

Originally Posted by Angus

It does by every definition of thread-safe that's been thrown at me. Foo() cannot be called again until it is finished, and the same criteria applies to goo(). If the definition were extended to imply that nothing else that isn't thread-safe can be trusted to run while foo() and goo() are running, that would be different, but that's not what I've been hearing.

---

Then you are one of the few people I've run into who has (mis) interpretted the definition in that way. A function is thread safe if it can tolerate multiple, simultaneous invokations. These "foo" and "goo" functions can't.

Quote:

---

It's not always that simple. This came up because I have these 2 close source libraries that I want to run concurrently. Unfortunately, neither appear to be thread-safe by any definition, so I've had to chuck all my threading code and go for a multi-process solution. It wouldn't make sense to put any reentrant wrapper around the library calls, since that would in effect make execution serial.

---

Yes, it sucks. Modern general-use libraries should be thread-safe.

Quote:

---

Originally Posted by brewbuck

Then you are one of the few people I've run into who has (mis) interpretted the definition in that way. A function is thread safe if it can tolerate multiple, simultaneous invokations. These "foo" and "goo" functions can't.

---

That's what I've been saying all along, foo() and goo() are not thread-safe. But because neither of them will experience 2 concurrent invocations they are being handled in a thread-safe manner. However, both might be called concurrently, so there's a problem.

Quote:

---

Originally Posted by Angus

That's what I've been saying all along, foo() and goo() are not thread-safe. But because neither of them will experience 2 concurrent invocations they are being handled in a thread-safe manner. However, both might be called concurrently, so there's a problem.

---

Which is why the definition of thread safe is always with respect to a single function. foo and goo are not "mutually unsafe," they are simply unsafe, period.

From wikipedia:
"Thread safety is a computer programming concept applicable in the context of multi-threaded programs. A piece of code is thread-safe if it functions correctly during simultaneous execution by multiple threads. In particular, it must satisfy the need for multiple threads to access the same shared data, and the need for a shared piece of data to be accessed by only one thread at any given time."

The last sentence is key to your question. For a function to be truly thread safe it needs to make sure shared data is accessed by only one thread at a time. Not just function correctly when called simultaneously from different contexts. eg the first condition:

Code:

---

int foo()
{
static int count =0;
count ++;

...
//point a

printf("this function has been called %d times\n", count);

...

//point b
return count;

}

---

foo() is not thread safe. It is called by a low priority thread and gets to point b, then a high priority thread calls it and returns, the result will not be what we expected (not agree with the printout).

Then the second condition:

Code:

---

int global_int = 0;
int hoo()
{
  if (global_int < 5)
  {
      //point a
      if (global_int == 5 )
      {
        printf("shouldnt get here!\n");
      }
      global_int+=5;
  }
}

goo()
{
  mutex_lock(global_int_protector);
  global_int++;
  mutex_unlock(global_int_protector);
}
woo ()
{
  mutex_lock(global_int_protector);
  global_int--;
  mutex_unlock(global_int_protector);
}

---

hoo() is not thread safe. Under the right conditions you may see the print out. It doesn't protect the global_int data even from other instances of itself. woo() and goo() are thread safe, however hoo can still cause corruption of global_int and thus cause them to act unexpectedly.

Have a look at:
Thread safety - Wikipedia, the free encyclopedia

this explains it quite well