Re: x86 instructions reordering

[Manuel Bouyer <bouyer%antioche.lip6.fr@localhost>]

On Fri, Mar 25, 2005 at 10:42:26AM +0900, Takayoshi Kochi wrote:
> Hi,
> 
> > So basically, the sender send an event only if the receiver isn't already 
> > busy.
> > But sometimes, the receiver stops and isn't getting an event. The only way I
> > can see this happen is if the read and writes to memory
> > don't happen in the intended order. This problem only occurs if the
> > reader and writer are running on different CPUs of the HT P4. I couldn't
> > reproduce this if I force both virtual machine to run on the same CPU, while
> > it locks up quickly if each virtual machine runs on a different virtual CPU.
> 
> Do you have any observation _where_ the sender or the reader locks up?

The reader isn't working, but it has b < a. The sender is still queuing
data in the shared memory (thus increasing a) but doesn't send an event to
wake up the receiver, as b < a.
calling handle_event() by some other way makes things go again.

> 
> I imagine from the arguments, that the sender doesn't call send_event()
> because it never sees (shared_memory->b == a) to be true.

Yes.

> At that point,
> are you sure the receiver has finished all the events and written its 'b'
> to shared_memory->b?

This I don't know. 

> 
> If the scheduling of the two virtual guest OSes are not equal, and
> the sender has priority, the receiver might not have enough time to
> handle all the events and keep busy all the time, which will fail to
> signal to the sender that the receiver is idle.

Here I don't follow you. If the receiver is too slow, then the 'goto again'
loop will never finish. The sender will never see the receiver idle,
but as the receiver is still in the loop it's fine.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--