<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 27/06/2011 14:23, Mattias Gaertner wrote:
    <blockquote
      cite="mid:1362108844.376553.1309181010082.JavaMail.open-xchange@cc-app2"
      type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <title></title>
      <p style="margin: 0px;"><span><br>
        </span></p>
      <div style="margin: 5px 0px;">
        <blockquote style="margin-left: 0px; padding-left: 10px;
          border-left: 1px solid blue;" type="cite">
          <blockquote type="cite">
            <blockquote type="cite"><br>
              What is "thread safe"?<br>
            </blockquote>
            <br>
            The definition is very clear here:<br>
            <br>
            <a moz-do-not-send="true"
              href="http://en.wikipedia.org/wiki/Thread_safety">http://en.wikipedia.org/wiki/Thread_safety</a><br>
          </blockquote>
          <br>
          "A piece of code is <strong>thread-safe</strong> if it can be
          safely invoked by multiple threads at the same time"<br>
          <br>
          Just to point out first, I am aware of the discussion this has
          already sparked, and in the light of any argument of that
          discussion, in my opinion this definition is correct.<br>
          <br>
          Yet I came to think of a case, for which I wonder, and would
          like to hear opinions, if indeed the above statement is
          complete.<br>
          My query is about the part: "at the same time" </blockquote>
      </div>
      <p style="margin: 0px;"> </p>
      <p style="margin: 0px;">Think about "safely invoked" as no need
        for extra precautions to call it multi threaded, like e.g.
        critical sections or check which thread is running. </p>
      <p style="margin: 0px;">Obviously "thread-safe" does not extend
        the safety nor does it fix any kind of flaw that is already
        there when called single threaded. </p>
      <p style="margin: 0px;">And "thread safe" does not mean that
        calling a function multi threaded will give the same results as
        called single threaded. Although typically it does. </p>
      <p style="margin: 0px;"> </p>
      <p style="margin: 0px;">And look up the definition of "function".
        A function is defined by the input, output and task. Failing
        means for some input the wrong output is returned. Input/Output
        are not only parameters. <br>
      </p>
    </blockquote>
    <br>
    Yes, but if I am correct, "input" for example can not (always) be
    limited to the list of param (not even including hidden param, like
    self)<br>
    eg, a constructor, includes the task of allocating memory. If that
    fails a defined behaviour should be expected (return nil, throw
    exception, ...). That implies, that "available memory" in this case
    is part of the input.<br>
    <br>
    Sure, similar flaws (with invalid data) can be constructed outside
    threads. But the ability to store data in either a variable local to
    one thread, or global to all threads does not exists without
    threads.<br>
    <br>
    Yes the aim of the definition, is solely to extend the concept of
    being called safely to being called safely from several threads. <br>
    But the above definition *limits* this requirement to "called at the
    same time"<br>
    <br>
    <br>
    <blockquote
      cite="mid:1362108844.376553.1309181010082.JavaMail.open-xchange@cc-app2"
      type="cite">
      <div style="margin: 5px 0px;">
        <blockquote style="margin-left: 0px; padding-left: 10px;
          border-left: 1px solid blue;" type="cite"> <br>
          Now a piece of code could for example mix up thread local and
          thread global data:<br>
          - cache access to thread local data in a thread global way.
          Subsequent calls from another thread may fail.<br>
          - create an initialize some data, and store it thread-local,
          while flagging it's existence thread global. Subsequent calls
          from another thread may fail. </blockquote>
      </div>
      <p style="margin: 0px;"> </p>
      <p style="margin: 0px;">The "fail" depends on how you define the
        task of the function.</p>
      <p style="margin: 0px;">I guess with "fail" you mean the function
        can fail its tasks when called multi threaded. Then it is by
        definition not thread safe.</p>
    </blockquote>
    <br>
    As I said, those examples, are not actually correct (for what I am
    questioning) They only point into a direction.<br>
    <br>
    fail = not the result that is expected according to the definition
    of the function (that could be: not return at all, crash, or return
    an incorrect value as result...)<br>
    <br>
    The example is merely to indicate, that thread related problems can
    occur, even if calls are "not at the same time".<br>
    <br>
    Yes similar issues can be constructed without threads. But without
    threads you do not have a differentiation between data accessible to
    just one thread, and data accessible to all threads. So problems
    arising from this, are thread related.<br>
    <br>
    <blockquote
      cite="mid:1362108844.376553.1309181010082.JavaMail.open-xchange@cc-app2"
      type="cite">
      <div style="margin: 5px 0px;">
        <blockquote style="margin-left: 0px; padding-left: 10px;
          border-left: 1px solid blue;" type="cite"> Even if such code
          was using some sort of locking (mutex, criticalsection, ...)
          it would fail. It would not need to be executed from several
          threads "at the same time", it fails if executed by several
          threads subsequently.<br>
          <br>
          However so far of course each of those would also fail, if
          called "at the same time". So all my examples are indeed
          covered by the original definition.<br>
          <br>
          The question is, is it prooven, or can it be prooven, that no
          code can be constructed, that would "not fail if called at the
          same time", but that would fail if called "subsequently" </blockquote>
      </div>
      <p style="margin: 0px;"> </p>
      <p style="margin: 0px;">"At the same time" includes
        "subsequently", for the simple reason that critical sections are
        allowed, which simply turns a parallel (at the same time) into a
        sequential one. <br>
      </p>
    </blockquote>
    <br>
    There is a difference between called/invoked at the same time, and
    executed at the same time.<br>
    <br>
    The original defintion says "invoked" they are still invoked at the
    same time, even though *if* a critical section is used, the part
    inside it (and only this part, not the whole piece of code, which
    includes the critical section) is executed deferred.<br>
    <br>
    "at the same time" does not necessarily mean a critical section has
    to exist, there are other means that allow for more parallel
    execution:<br>
     2 read only calls, may not need to block each other at all. Yet a
    read-only  call may fail due to something thread related, that
    happened long before (in an other thread, and only because it
    happened in an other thread).<br>
    <br>
  </body>
</html>