3
strcmp(variable, "constant");

Or do I have to protect it with a mutex?

j riv
  • 3,593
  • 6
  • 39
  • 54
  • 1
    You can replace "rand_r" with "strcmp" in this answer. http://stackoverflow.com/questions/2772090/whether-rand-r-is-real-thread-safe/2772340#2772340, and note that when I say "acting on data", it's only an issue if one or more of the threads involved modifies the data. – Steve Jessop Dec 06 '10 at 10:30

5 Answers5

5

If variable can be modified by other thread you must protect it. No magic here – higher level languages could do such function call atomically and that is the 'magic' not present in C.

Please note that protection (by a single lock) need both the 'variable' pointer value (address of the string in the memory) and the string itself (note: it could be referenced by other pointer too). If the string is modified while 'strcmp' is running you could get false result or a buffer overflow and a segmentation fault.

Jacek Konieczny
  • 8,283
  • 2
  • 23
  • 35
  • Did you mean "constant" (in parentheses) needs protection too? That sounds bizarre. – j riv Dec 06 '10 at 10:06
  • 1
    No - Jacek doesn't mean the constant, he means a pointer to variable. If you had, char *myPointer = someString; strcmp(myPointer, "constant") then you'll need to protect both what myPointer points to and myPointer itself if you want a consistent result. – Jackson Dec 06 '10 at 10:33
2

Locks protect data, not code.

Since strcmp has no way of knowing what lock you might be using to protect variable, there's no way it could possibly acquire that lock, so the function is not "thread-safe" in the sense you probably mean.

Steve Jessop
  • 273,490
  • 39
  • 460
  • 699
1

You need to protect access to variable if it is shared.
Multiple threads calling strcmp is safe by itself (functionality wise) since, strcmp just compares the 2 strings and does no modification.
But since the variable could have been changed by other thread while strcmp is running, modification could break strcmp during its operation so you should guard it along with all the other places you access variable.

Cratylus
  • 52,998
  • 69
  • 209
  • 339
  • I wonder if the implementation has the right to mess it up even if variable is not explicitly changed. – j riv Dec 06 '10 at 10:13
  • @Lela: depends what you mean by "the right". There's no such thing as threads in the C standard, so technically an implementation can define threads however it likes. In practice, all thread models that I know of (including pthreads) permit concurrent reads provided that there are no writes, although I'm not sure exactly where the concurrent memory model is documented for pthreads. – Steve Jessop Dec 06 '10 at 10:33
  • I know; It becomes worrisome if you do multi-platform. You can't just rely to "oh Microsoft does it that way" etc. – j riv Dec 06 '10 at 10:41
0

It's safe. The parameters and any internal variables go on the stack so are different memory to any other threads that may be calling the same function.

AlastairG
  • 4,119
  • 5
  • 26
  • 41
  • What if variable changes by something else? also I wonder if the implementation can mess it up without variable changing being done explicitly. – j riv Dec 06 '10 at 10:13
  • That someone else is you, if you have created threads that can change either of the arguments to strcmp, you're responsible for providing sufficient locking. Also, the implementation doesn't mess up. – nos Dec 06 '10 at 10:38
  • I meant, since the standard does not mention multithreading, could a compiler optimization basically free it/lock it/etc. while the main thread doesn't need it, so the thread may go and find it and get 'oops, not here'? [I wonder though how could a mutex protect from that since it's basically a boolean locking threads out.] – j riv Dec 06 '10 at 10:52
  • 1
    @Lela I don't understand what you are trying to say. Buffer overflows or stack overflows may overwrite the stack or memory pointed to by passed in parameters, but that is not an issue with the "thread safe"ness of strcmp but an issue with whatever is corrupting memory. strcmp() itself is thread safe since it only reads the memory. – AlastairG Dec 06 '10 at 11:06
  • @AlistairG: you may be defining "thread-safe" differently from Lela, and generally Posix defines "thread-safe" differently from some other things such as Java: http://stackoverflow.com/questions/2772090/whether-rand-r-is-real-thread-safe/2772340#2772340. In the wider sense it *is* an issue with thread-safety, but `strcmp` is what C programmers usually mean when they say "safe". It's just a question of how safe something has to be before it's called "safe". – Steve Jessop Dec 06 '10 at 12:52
  • @Steve: Since the input to strcmp() is not owned by the component/library that implements strcmp() it is certain that level 3 thread-safeness (as defined by your link) cannot be guaranteed. Functions can only be thread-safe with respect to the data they handle if the component or library they are part of controls ALL accesses to the data. Even if strcmp did implement a mutex lock around its internals, every other peice of code modifying the data would need to lock the same mutex for it to be thread-safe, which is impossible since the string library doesn't publish a mutex. – AlastairG Dec 06 '10 at 13:00
  • All this is just common sense, surely? Hence I don't understand what Lela is trying to ask. – AlastairG Dec 06 '10 at 13:01
  • @Alistair: I agree that it's common sense, but it's common sense specific to C, which takes some time (and questions) to develop. The "common-sense" answer in other languages might be different. Even in Java people acknowledge that bundling a lock with every object, that "thread-safe" functions on that object can synchronize with, doesn't always work. But it does result in a different common sense meaning of "thread-safe". – Steve Jessop Dec 06 '10 at 13:07
  • So in Java one might want to say that `strcmp` is only thread-safe if it does `synchronized(variable)` (presuming variable is mutable). Not that this would actually work in Java in this case: you'd get locking inversions because `strcmp` takes two parameters. My point is just that "thread-safe" isn't a universal concept, so it seems fairly natural to me that people are going to need to ask what it means in C (or guess and guess wrong). – Steve Jessop Dec 06 '10 at 13:10
0

Look here: http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html

There is a list of thread-unsafe functions in POSIX. Accordingly to it at least on POSIX strcmp() would be thread-safe.

Vovanium
  • 3,798
  • 17
  • 23