~pmdj/ubuntu/trusty/qemu/2.9+applesmc+fadtv3

« back to all changes in this revision

Viewing changes to docs/multiple-iothreads.txt

  • Committer: Phil Dennis-Jordan
  • Date: 2017-07-21 08:03:43 UTC
  • mfrom: (1.1.1)
  • Revision ID: phil@philjordan.eu-20170721080343-2yr2vdj7713czahv
New upstream release 2.9.0.

Show diffs side-by-side

added added

removed removed

Lines of Context:
84
84
AioContext is not thread-safe so some rules must be followed when using file
85
85
descriptors, event notifiers, timers, or BHs across threads:
86
86
 
87
 
1. AioContext functions can be called safely from file descriptor, event
88
 
notifier, timer, or BH callbacks invoked by the AioContext.  No locking is
89
 
necessary.
 
87
1. AioContext functions can always be called safely.  They handle their
 
88
own locking internally.
90
89
 
91
90
2. Other threads wishing to access the AioContext must use
92
91
aio_context_acquire()/aio_context_release() for mutual exclusion.  Once the
94
93
in this AioContext.
95
94
 
96
95
aio_context_acquire()/aio_context_release() calls may be nested.  This
97
 
means you can call them if you're not sure whether #1 applies.
 
96
means you can call them if you're not sure whether #2 applies.
98
97
 
99
98
There is currently no lock ordering rule if a thread needs to acquire multiple
100
99
AioContexts simultaneously.  Therefore, it is only safe for code holding the
101
100
QEMU global mutex to acquire other AioContexts.
102
101
 
103
 
Side note: the best way to schedule a function call across threads is to create
104
 
a BH in the target AioContext beforehand and then call qemu_bh_schedule().  No
105
 
acquire/release or locking is needed for the qemu_bh_schedule() call.  But be
106
 
sure to acquire the AioContext for aio_bh_new() if necessary.
 
102
Side note: the best way to schedule a function call across threads is to call
 
103
aio_bh_schedule_oneshot().  No acquire/release or locking is needed.
107
104
 
108
105
AioContext and the block layer
109
106
------------------------------