Tom Moers wrote:
> Did you even look at the diagrammed scenario?
Yes, and it's what I described in my very first reply to you. We're not
disagreeing on what *can* happen. We're disagreeing on what is *likely*
> I'm contending that the diagrammed scenario is possible with
> your example as it is now; not because of thread creation times,
> but because of the 6 'grab, use and release connection' iterations
> that each of your 14 threads make: it is possible that a connection
> is created and released in one thread and then grabbed by a
> different thread before the creator thread reuses it.
This is where you're getting confused. It doesn't matter if thread 2
uses a connection created by thread 1 *if* thread 2 has registered
itself with the C API library. It does that either implicitly by
creating at least one connection of its own, or by explicitly by calling
mysql_thread_start(). Once that has been done, it never has to be done
again as long as the thread runs, no matter which connections it uses.
Since creating a connection registers the thread with the C API library,
all is well as long as all 14 threads call grab() before any of them
call release(). It's as simple as that. Given enough context switches
or system load, or change the number of threads or what they do, and the
assumption that you can do this is invalid. In this simple example, it
seems to work fine.
There is no necessary tie between connections and thread registration.
It just happens to be done implicitly by the library when requesting the
first connection as a convenience, since this is the first operation a
single-threaded program will normally do. You have to keep that
single-threaded perspective in mind when thinking about MySQL. The
library was created with that in mind, and thread-awareness tacked on
after the fact.
It may help you to clear this up by reading this section in the C API :