* Ingo Strüwing <Ingo.Struewing@stripped> [09/05/06 20:03]:
> Ok, here is, what I thought could happen:
>
> Thread_1
> --------
> Event_queue::get_top_for_execution_if_time()
> {
> ...
> if (thd->killed)
> ... // not killed yet
> Thread_2
> --------
> THD:awake()
> {
> thd_1->killed= KILL_CONNECTION;
> ...
> if (thd_1->mysys_var->current_cond &&
> thd_1->mysys_var->current_mutex)
> ... // not set yet
> }
> ...
>
>
> enter_cond() // set
> // mysys_var->current_cond
> // && current_mutex
> pthread_cond_wait()
> // hang, wait for next kill
> ...
>
> ...
> }
>
> If repeating if(thd->killed) after enter_cond(), the KILL would be
> detected immediately. If it isn't present at this time either, awake()
> would find the mysys_var values after setting it, and broadcast the
> condition.
>
> OTOH, I learned from Davi, that there is no guarantee that thread_1 sees
> the new value of "killed" immediately after thread_2 sets it. So my idea
> may be pointless. Killing won't become reliable anyway.
OK, now it is making sense to me. That is, assuming there is cache
coherency and no write reordering.
But then what's the point of checking it twice -- why is it not
enough to check before we fall into pthread_cond_wait() and after
calling enter_cond()?
--
