Talk:Reentrancy (computing)

message: Here is a function which is idempotent but not reentrant:
 int global;
 int f(int * i)
 {
   global++;
   *i = global;
   global--;
 }
Or am I misunderstanding something?  —Preceding unsigned comment added by 199.172.169.86 (talk) 10:15, 25 February 2011 (UTC)
replies: text: I believe you're correct. That seemed odd to me too. I've removed the claim. spikey (talk) 16:05, 15 April 2014 (UTC)
thread_title:  Incorrect claim "Idempotence implies reentrancy, but the contrary is not necessary true." 

message: I don't know very much about functional programming, but aren't functional programming languages reentrant (variables and functions, and even syntax (in Scheme for example) ? —Preceding unsigned comment added by 83.214.221.148 (talk • contribs) 
: I don't know about Scheme, but I would say that purely functional languages like Haskell are inherently reentrant (except for the IO monad). --Pezezin 22:57, 19 March 2007 (UTC)
thread_title:  Functional programming 

message: I think the definition is too sloppy: Consider the case of an object oriented language. An object x could refer to another object y. Now a method in the class of object x returns a value which depends on the state of object y. If the class of object y is mutable, then this is a side effect which influences the result of the method.
Now the problem with the definition is that in its strict sense, this method *is* re-entrant because there is no static data involved in this example. But I am led to believe that in its true meaning the method is *not* reentrant because the return value depends on side effects.
So I suggest the following definition: A reentrant piece of code is a pure function in mathematical terms, which means that its output solely depends on its input parameters, without any side effects.
This implies that the piece of code cannot use static, global or any other data which is not an input parameter. It also implies that the code cannot call other code which does not obeye these requirements. Finally, it implies that the piece of code is thread safe, because the code can only use variables which are local to the current thread (which are usually held on the stack by most programming languages). —Preceding unsigned comment added by 217.83.33.125 (talk • contribs) 
:But that is not what "reentrant" means in most contexts. While a function taking only immutable arguments is indeed reentrant by definition, it's not particularly useful in real life - passing references to complex mutable objects is much more efficient and useful in many cases. As far as I know, "reentrant" does not imply the complete lack of side-effects, but merely that the API is designed with reentrancy in mind. -- intgr 14:04, 10 November 2006 (UTC)
replies: text: Java's String class is immutable. Its methods take other String objects and primitives as arguments. All these methods would be reentrant according to my definition. I don't think that they are not particularly useful - to the contrary: I couldn't do without them. Regarding the term "reentrancy in mind": Well, unless we have a clear definition of the term reentrant, we couldn't even argue what this term means. 217.83.74.51 10:23, 16 November 2006 (UTC)
replies: text: The String class is an exception rather than the rule – nearly all methods taking Strings as arguments are bound to a mutable class anyway. My "reentrancy in mind" comment above relied on the original definition on the article: "[A] routine is described as reentrant if it can be safely called recursively or from multiple processes". -- intgr 15:40, 16 November 2006 (UTC)

text: I agree with intgr : functions whose output solely depends on its input parameters without any side effects is a sufficient requirement for reentrancy; however, it's not a necessary one.  In fact, if that were necessary and sufficient, we wouldn't need all the other items on the list (not that the other items in the list hold all that much value either).  As a counter-example to what's proposed, let's imagine that we have a processing queue that has a counter for how many items are in the queue.  This counter can be read without a lock.  You might get a slightly stale value if you read it when another thread is updating it (but all values are instantly stale anyway).  A function that reads and returns the value of this counter is useful and reentrant, though it operates on global non-static data.  Acertain (talk) 03:36, 28 December 2009 (UTC)
thread_title:  Alternative 

message: int f(int i)
 {
   int priv = i;
   priv = priv + 2;
   return priv;
 }
 
 int g(int i)
 {
   int priv = i;
   return f(priv) + 2;
 }
 
 int main()
 {
   g(1);
   return 0;
 }
Why is this example reentrant? Is priv unique to each simultaneous process/thread or is it shared by all? --Abdull 10:40, 13 July 2007 (UTC)
replies: text: priv is unique to each execution of f() and g() because priv is allocated on the stack of the current thread. Possibly this could be mentioned in the article, but I don't think it's necessary, either. -- Johngiors 06:50, 26 September 2007 (UTC)
thread_title:  Why? 

message: int f(int i)
 {
   return i + 2;
 }
 
 int g(int i)
 {
   return f(i) + 2;
 }
 
 int main()
 {
   g(1);
   return 0;
 }
the parameter values are unique for each call. —Preceding unsigned comment added by 85.144.94.32 (talk) 13:59, 1 May 2008 (UTC)
thread_title:  Why not? 

message: "Despite a common misconception, this is not the same as being designed in such a way that a single copy of the program's instructions, in memory, can be shared."
:So, what is the term/buzzword for that? Is it Thread safety? In which case, it should be added to the sentence, and the "See Also" section could be removed.
--Jerome Potts 17:16, 19 August 2007 (UTC)
replies: text: removed that line bc it doesn't make sense; whether or not the executable code is physically shared among processes would only seem relevant for self-modifying code, which nobody uses. author probably meant the data on the heap, not the "instructions"... but still, its not useful. 12.219.83.157 06:05, 16 September 2007 (UTC)
thread_title:  the common misconception 

message: Sections of this article are almost redundant copies of the first external link:
http://www.ibm.com/developerworks/linux/library/l-reent.html
Compare:
Reentrance and thread-safety are separate concepts: a function can be either reentrant, thread-safe, both, or neither...
and
Non-reentrant functions are thread-unsafe. Furthermore, it may be impossible to make a non-reentrant function thread-safe.
to:
Don't confuse reentrance with thread-safety. From the programmer perspective, these two are separate concepts: a function can be reentrant, thread-safe, both, or neither. Non-reentrant functions cannot be used by multiple threads. Moreover, it may be impossible to make a non-reentrant function thread-safe.
TheShagg 20:26, 12 October 2007 (UTC)
thread_title:  Almost blatently copied 

message: I don't think the following statement is correct:
"Non-reentrant functions are thread-unsafe. Furthermore, it may be impossible to make a non-reentrant function thread-safe."
I think you can have a thread safe function that is non reentrant. Maybe the write meant something like this?
"Thread-unsafe functions are non-reentrant. Furthermore, it may be [or even is] impossible to make a thread-unsafe function reentrant"  —Preceding unsigned comment added by Hnassif (talk • contribs) 17:30, 19 October 2007 (UTC)
replies: text: Right now it states "Non-reentrant functions are not thread-safe. Furthermore, it may be impossible to make a non-reentrant function thread-safe (quote?).". This does not make any sense at all, particularly coupled with the statement at the beginning "Reentrance is stronger property than thread-safety: a function can be thread-safe, both, or neither.".  —Preceding unsigned comment added by 87.166.65.202 (talk) 17:54, 14 January 2008 (UTC)
thread_title:  Relation to thread safety 

message: Ad ads ;). There's been mentioned 2 guys for no aparent reason. It is nice they recomend something, sure. Your favourite OS teacher doesn't?
Explanations. I thought it might be nice to add some explanations for girls, who cram, and guys, who are just mildly curious. I also called it a derivation. It might not be a best name. Feel free to change mine mistakes ;).
Simplification. There we're 2 sentences which I thought would better be swapped. To me the second seemed more like natural explanation. Hmm
Citations. There are few claims in "derivation and explanation of rules" that I have no support. I am too lazy to look it up and ,hey, wiki-kids might practice google hunting. 86.61.232.26 (talk) 23:56, 26 April 2009 (UTC)
thread_title:  (-) ads (+) added explanations (-) simplified intro (!) citation needed 

message: We are given two examples of best practise: 're-enable interrupts as soon as possible', and 'avoid early re-enabling of interrupts unless it is necessary'. These would appear to be mutually exclusive.
On a tangent: why does the article use 're-enable' and 're-entered', but then use the dubious 'reentrant'? Shouldn't it be re-entrant?  —Preceding unsigned comment added by 59.95.22.6 (talk) 18:36, 20 November 2009 (UTC)
thread_title:  Reentrant interrupt handler 

message: Is there a difference between the concepts of a re-entrant function a pure function? What about locks to singleton objects - is that a point of difference?
If they are the same, then this should be pointed out in both articles (see pure function). Otherwise, I think the difference ought to be explained, as it would make the definition richer.
Does anyone know the difference (and a few definitive sources to cite)? 203.171.122.38 (talk) 09:46, 23 October 2010 (UTC)
thread_title:  Difference of "re-entrant" and "pure" 

message: The long runs of italic text in the Derivations section is hard to read. Are these a quote? If so, that should be explicit. Normal text with perhaps a numbered list or bullet list would be easier to read. Sluggoster (talk) 17:51, 9 November 2010 (UTC)
thread_title:  Italics 

message: A yet another glaring factual error: this version claimed reentrancy is a requirement for recursion.  It's not, for two reasons:
* recursive calls can happen only explicitely, unlike interrupts, so this code works:
  void f(int x)
  {
      acquire_global_data();
      mess_with_global_data(x);
      release_global_data();
      if (x > 0)
          f(x - 1);
  }
* possible arguments for a recursive call may be a subset of those called from the outside:
  void process_dir_and_parents(char *path)
  {
      if (!path || *path != '/')
          path = get_absolute_path(path); // not reentrant
      process_dir(path);
      chop_last_element(path);
      if (*path)
          process_dir_and_parents(path); // here, the path is always absolute
  }
KiloByte (talk) 13:36, 26 May 2012 (UTC)
replies: text: While I don't want to defend the old text, your new wording is at best ambiguous with a possible interpretation that is factually inaccurate as well. I think it would have been better if you had simply removed the old statement. —Ruud 13:59, 26 May 2012 (UTC)
replies: text:  Good idea, I removed this, together with an unrelated vague statement about functional programming as well. KiloByte (talk) 22:45, 26 May 2012 (UTC)

text: What I assume the old text intended: non-reentrant functions usually break some invariant that is expected to hold on entry during execution, but re-establish it before exit. However if you make the recursive call while the invariant is broken things may go wrong. —Ruud 14:04, 26 May 2012 (UTC)
thread_title:  Reentrancy vs recursion 

message: The page gives an example of a function.
int g_var = 1;
int f()
{
    g_var = g_var + 2;
    return g_var;
}
f is not thread-safe. Then the article literally concludes from the non-thread-safety "Hence, f is not reentrant". First, the article itself explains that functions can be reentrant and not thread-safe. Second, Qt's page on reentrancy  gives basically the same code as an example of a reentrant function. It does not return the value, but that is not part of the definition of reentrancy, and the member variable might as well be global static if you use a static instance of the class.
class Counter
{
  int n;
public:
  void increment() { ++n; }
}
80.153.93.87 (talk) 15:46, 13 January 2016 (UTC)
thread_title:  Further example is wrong 

message: do you think that the last paragraph about the atomicity requirement in the current introduction of the article is correct? To me atomicity is not necessary, as demonstrated by the 3rd example in the article (Reentrant but not thread-safe), where tmp is a global variable that is not modified atomically.
: Maggyero (talk) 07:39, 25 June 2018 (UTC)
thread_title:  Unnecessary atomicity requirement 

message: The claim It is a concept from the time when no multitasking operating systems existed. is false. The concept originated with OS/360 Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:03, 20 August 2018 (UTC)
thread_title:  Provenance of reentrancy 

message: I have a computer science background but am new to this concept. I found Reentrancy_(computing)#Reentrant_but_not_thread-safe to be unnecessarily confusing because of the recently added comment in the code: /*If hardware interrupt occurs here then it will fail to keep the value of tmp. So this is also not a reentrant example*/
This is self-contradictory because the name of the section and the description preceding the code example say that it is reentrant. I see in the edit history that this comment was added, removed, readded within the last few months.
I think we can agree that the article as a whole would be better if there isn't a part that says two opposing things simultaneously, right? Rather than leaving it as it is now, someone who knows this stuff better than me should clarify the ambiguities so that it's no longer possible to interpret the description and example in different "contexts" to arrive at different conclusions about whether it's reentrant or not. Maybe adding to the description something like "assuming that the ISR itself can't be interrupted and there is only 1 processor, so the ISR will finish and swap its 2 ints correctly before restoring tmp so that the interrupted instance will still see the value it expects in tmp"
Citizenofinfinity (talk) 11:11, 19 February 2021 (UTC)
thread_title:  The self-contradiction in the "Reentrant but not thread-safe" example should be fixed 

message: The code in #Reentrant but not thread-safe is not reentrant unless it is running on a uniprocessor with interrupts disabled.
int tmp;
void swap(int* x, int* y)
{
    /* Save global variable. */
    int s;
    s = tmp;
    tmp = *x;
    *x = *y;
    *y = tmp;     /* Hardware interrupt might invoke isr() here. */
    /* Restore global variable. */
    tmp = s;
}
void isr()
{
    int x = 1, y = 2;
    swap(&x, &y);
}
There is no serialization on the global variable  between  and . --Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:03, 13 February 2022 (UTC)
thread_title:  The code in Reentrant but not thread-safe is not reentrant 

message: A recent edit added an incorrect short description. I was going to correct it but then I realized that I had come up with text that was much two long. So, the question is, how to word it so that it covers both scenarios below without being verbose?
#Foo calls Baz on CPU A and at approximately the same time Bar calls Baz on CPU B. No interrupt is involved.
#Foo calls Baz on CPU A, Foo is interrupted, Bar is dispatched on CPU A, Bar calls Baz, periodically interrupts cause alternating dispatches of Foo and Bar, with the two invocations of Baz interleaved on a coarse time frame.
In both cases Baz has to deal with serialization of data. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:57, 19 February 2023 (UTC)
replies: text: I’m ashamed to say I’m not a computer scientist, I just skimmed the introduction and tried to summarize it as best I could. If the concept is that complicated it's probably better to just set the short description as "concept in computer programming" and leave it at that OlliverWithDoubleL (talk) 23:24, 19 February 2023 (UTC)
thread_title:  Short description