[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH -V3 09/32] virtio-9p: Implement P9_TWRITE/ Threa
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] [PATCH -V3 09/32] virtio-9p: Implement P9_TWRITE/ Thread model in QEMU |
Date: |
Thu, 1 Apr 2010 15:30:29 +0000 |
User-agent: |
KMail/1.12.4 (Linux/2.6.32-trunk-amd64; KDE/4.3.4; x86_64; ; ) |
> 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