35

I came across this line "some functions are inherently thread-safe, for example memcpy()"

Wikipedia defines "thread-safe" as:

A piece of code is thread-safe if it only manipulates shared data structures in a manner that guarantees safe execution by multiple threads at the same time.

OK. But what does inherently mean? Is it related to inheritance?

laurent
  • 88,262
  • 77
  • 290
  • 428
Vikram
  • 1,999
  • 3
  • 23
  • 35
  • Why is memcpy inherently thread-safe? Cannot it copy data between buffers shared amongst threads? – Thilo Apr 07 '14 at 09:36
  • 1
    @Thilo I read it here - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0349c/Chdfgjej.html – Vikram Apr 07 '14 at 09:41
  • The thread safety of memcpy seems to be quite OS dependent: http://stackoverflow.com/questions/15145152/is-memcpy-process-safe Not something I'd call *inherently safe* (even if it happens to be so on a particular platform) – Thilo Apr 07 '14 at 09:48
  • 60
    Looks like you have an English confusion, not a programming one. The words "inherent" and "inherit" are unrelated: http://dictionary.reference.com/browse/inherent – user2357112 Apr 07 '14 at 09:51
  • 15
    What's funny is that the quoted sentence is absurd beyond measure. While `memcpy` of course doesn't need to touch shared state (and thus is _naively_ thread-safe), it modifies _arbitrary memory regions_ in an unsynchronized manner, which is very obviously not thread-safe at all. – Damon Apr 07 '14 at 16:36
  • @Damon is the Wikipedia quote absurd or ARM attaching "inherently" to their description when saying `memcpy`, `memmove`, etc. are thread-safe? I could imagine some DMA controller copying arbitrary blocks of memory in an atomic fashion. – Nick T Apr 07 '14 at 17:57
  • 1
    Well, should the tag [tag:inheritance] be removed from question then? – user1306322 Apr 07 '14 at 18:13
  • @NickT: The description in ARM's docs is. The way this is worded, one should be led to believe that e.g. doing a `memcpy` to a buffer in one thread and reading from another thread (maybe also with `memcpy`) would give consistent results. Which obviously isn't the case, not even if some DMA controller does the heavy lifting (as memory tends to be logically organized in pages and physically organized in banks, this is simply not possible except for contrieved special cases). – Damon Apr 07 '14 at 18:27
  • 5
    @Damon: the so-called "absurd" quote is using the definition of "thread-safe" from the Posix standard. `memcpy` is required by Posix to be thread-safe under that definition. The quote from Wikipedia is not necessarily consistent with this definition, although it could be if we were *very* careful what we mean by "shared data structures". So, it is only absurd to you because you miss the context in which "thread-safe" is defined. The tags are unfortunate since the usual meaning of "thread-safe" in Java is different from the usual meaning in C. – Steve Jessop Apr 07 '14 at 22:20
  • 1
    @user2357112: No this is not "an English confusion". He merely took a guess at what the phrase meant. That guess was wrong, but the question is what **does** "inherently thread-safe" mean. When you are writing documentation of API or protocols, it's important to be exact. – Harold R. Eason Apr 08 '14 at 07:29
  • 1
    @HaroldR.Eason interpreting "inherently" to be related to "inheritance" indicates a language confusion. Nowhere is inheritance mentioned in the quote he lists as the source of the word... – jwenting Apr 08 '14 at 08:28
  • @jwenting: There's an expression in English that goes, "taking a stab at it", and a similar "shot in the dark". Look them up. The only confusion going on here is 57 people misinterpreting this question ("what does inherently thread safe-mean?") as "does inherently thread safe have something to do with inheritance?". Obviously they didn't *all* actually misinterpret the question (people aren't that stupid on average) - rather, they were being disingenuous. – Harold R. Eason Apr 12 '14 at 11:22

5 Answers5

64

It is not related to inheritance. It is an informal expression and means more like
"some functions are thread-safe by their nature". For example a function which does not
touch any shared values/state is thread safe anyway i.e. "is inherently thread-safe".

peter.petrov
  • 38,363
  • 16
  • 94
  • 159
  • 7
    +1 for "by their nature" (as opposed to having to take special precautions to make them threadsafe ). – Thilo Apr 07 '14 at 09:34
  • 11
    It's indeed not related to inheritance. The dictionary definition is even "Inherently - Existing as an essential constituent or characteristic; intrinsic." – nos Apr 07 '14 at 09:34
  • 2
    Interesting. I always thoght that "inherent" and "inherited" were related. Like "inherent" = "quality that is undoubtfully present because of the ancestry/inheritance/belonging to a group". But looks like thay have different roots indeed ("heredito" vs. "haereo"). – Ark-kun Apr 07 '14 at 18:27
  • 1
    +1 for pointing out that it's an informal expression without a technical, precise meaning. – Kevin Apr 08 '14 at 01:35
16

In this context I interpret it as "without having been designed to achieve it, it still is thread-safe".

There is no direct link to the concept of inheritance, although of course the words are related. This is not an example of inheritance in the object-oriented programming sense, of course. This is just a function, that from its core nature gets the property of being thread-safe.

Of course there's nothing magic about memcpy() being inherently thread-safe, either. Any function without internal state or "shared" side-effects will be so, which is why functional programming, where all functions are supposed to be "pure" and lack side-effects, lends itself so well to parallel programming.

In practice it's hard on typical computers to get "real work" done without side-effects, particularly I/O is very much defined by its side-effects. So even pure functional languages often have some non-functional corners.

Update: Of course, memcpy() is not free from side-effects, it's core purpose is to manipulate memory which, if shared between threads, certainly isn't safe. The assumption has to be that as long as the destination areas are distinct, it doesn't matter if one or more threads run memcpy() in parallel.

Contrast this with e.g. printf(), which generates characters on a single (for the process) output stream. It has to be explicitly implemented (as required by POSIX) to be thread-safe, whereas memcpy() does not.

unwind
  • 391,730
  • 64
  • 469
  • 606
  • 3
    How are the words related? I see an Indo-European ghē- mentioned in a dictionary for "inheritance" but I don't know if it's the same root as "inherent" or not... – Steve Jessop Apr 07 '14 at 15:13
  • 2
    @SteveJessop They aren't related at all, semantically. See the question comments and peter.petrov's answer. They *may* share some etymology, but I wouldn't bet on it either. –  Apr 07 '14 at 15:31
  • 1
    @delnan: right, I've seen those statements. This answer agrees the programming concepts aren't related. But if unwind is going to lay some PIE on me and prove his separate claim that the *words* are semantically related on the grounds that "to inhere" has the same root as Latin "hereditas", then I would enjoy that, so I'm hoping he will :-) One still might dispute that such a relationship is "obvious", but if it's just a matter of what general knowledge you have then that's obvious to those who know and not to those who don't. – Steve Jessop Apr 07 '14 at 15:41
9

An inherently thread safe function, is safe without having to take any specific design decisions regarding threading, it is thread safe simply by virtue of the task it performs as opposed to being redesigned to force thread safety. Say I write the very simple function:

int cube(int x)
{
    return x*x*x;
}

It is inherently thread safe, as it has no way of reading from or writing to shared memory. However I could also make a function which is not thread safe but make it thread safe through specific design and synchronization. Say I have this similar function to before:

void cubeshare()
{
    static int x;
    x = x * x * x;
    printf("%l", x);
}

This is not thread safe, it is entirely possible it could have the value of x change between each use (well this is actually unlikely in reality as x would get cached but lets say we are not doing any optimization).

We however could make this thread safe like this (this is pseudo code, a real mutex is more complicated):

void cubesharesafe(mutex foo)
{
    static int x;
    lockmutex(foo);
    x = x * x * x;
    printf("%l", x);
    unlockmutex(foo);
}

This is however not inherently thread safe, we are forcing it to be through redesign. Real examples will often be far more complicated than this but I hope that this gives an idea taken to the most simple possible level. If you have any questions please comment bellow.

Vality
  • 6,577
  • 3
  • 27
  • 48
  • @SteveJessop Hi, any chance you could take a look and see if this example is better? thanks. – Vality Apr 07 '14 at 18:36
  • @SteveJessop: A typical `memcpy` implementation will be non-blocking and thread-safe if not used to write memory which may be used by another thread, nor read memory which may be written by another thread. An implementation which would use a DMA controller to perform moves larger than a certain size might be faster than a typical implementation, but could likely not be both non-blocking and thread-safe without OS assistance even if all memory areas accessed by different threads were completely disjoint. – supercat Apr 07 '14 at 19:12
  • @Vality: yes, to me that is probably what the original quotation means by saying `memcpy` is "inherently" thread-safe. – Steve Jessop Apr 07 '14 at 22:19
4

In case of memcpy, only a single thread is able to provide writes from a specific source to a specific destination. : thread-safe by initial design so.

Inherently means: without needing to "tune" the base function to achieve the goal, in this case: thread safety.

If multiple threads could interfere the same "channel" at the same time, you would end up with problem of thread-safety related to shared chucks of data.

Mik378
  • 21,881
  • 15
  • 82
  • 180
  • 1
    Of course multiple threads can call memcpy simultaneously to write to the same destination, but the disastrous results are not the fault of memcpy, but the result of the caller doing something stupid. On the other hand, strtok is _not_ thread safe, even when two callers do completely unrelated things. And that is caused by the design of the interface, so it is _inherently_ not thread safe. – gnasher729 Apr 07 '14 at 12:19
1

inherent means Existing in something as a permanent. it has nothing to do with inheritance.. by default,or already some methods are thread safe...in order to protect or avoid multitasking problems.. vector,hash table..are some of the example classes that are inherently thread safe.. nothing..confusing..there are some functions..which is thread safe by default..

Lijo
  • 6,498
  • 5
  • 49
  • 60