Re: [Qemu-devel] [PATCH -V3 09/32] virtio-9p: Implement P9_TWRITE/ Thread model in QEMU

[Paul Brook <paul@codesourcery.com>]

> On 04/01/2010 04:14 PM, Paul Brook wrote:
> >>> On a philosophical note, threads may be easier to model complex
> >>> hardware that includes a processor, for example our scsi card (and how
> >>> about using tcg as a jit to boost it :)
> >>
> >> Yeah, it's hard to argue that script evaluation shouldn't be done in a
> >> thread.  But that doesn't prevent me from being very cautious about how
> >> and where we use threading :-)
> >
> > I agree that making script execution asynchronous is a good thing,
> > however I'm not convinced that (3) is the best way to do this. It's
> > certainly the most flexible model, however it also places responsibility
> > for locking/correctness on the device developer.
> >
> > A more limited scheme (e.g. asynchronous callbacks) can actually be
> > significant advantage. By forcing the developer to solve the problem in a
> > particular way we significantly reduce the scope for race conditions, and
> > hopefully restrict all locking concerns to common code/APIs.
> 
> Can you elaborate?  When would the callbacks be called?  When would the
> callbacks yield back? If the script isn't run to completion (a halt 
instruction), there isn't really a good answer to these questions.

In practice I don't think pre-emtive multithreading actually solves all that 
many problems. If a script enters an indefinite loop then you want to be 
terminating or throttling it anyway.  The difference is whether you 
yield/return or drop locks and performing a blocking operation.

I suppose what I'm getting at is the difference between explicit 
multithreading and event based programming.  In the latter case I believe it's 
much easier to have individual devices use a sequential model, but have the 
whole system be concurrent.

> > [1] This issue may come from accidental misuse of terminology, but it's
> > an important distinction.
> 
> Missing reference to footnote.

I was going to comment on the difference between re-entrancy and concurrency, 
but decided against it.

Paul