Time to commit remote ops for VirtualAllocEx, CreateRemoteThread

[Dan Kegel]

On 8/4/06, Thomas Kho <tkho at ucla.edu> wrote:
> > > Tommy's APC version of his
> > > VirtualAllocEx / CreateRemoteThread patch
> > > seems to be safe (since APCs only run a points where threads
> > > in well-written programs are not holding locks),
> >
> > Unfortunately there's no such guarantee, kernel APCs will run on every
> > wait.
>
> I'm not too clear why this is a problem.

The closest Alexandre has come to answering this is
http://www.mail-archive.com/wine-devel@winehq.org/msg29265.html
but with APCs we at least handle one of his two objections
(an APC definitely doesn't interrupt any critical section initialization).
leaving
"One problem is that many locks have to be acquired in a specific order
to avoid deadlocks, and since you don't know which locks the thread is
already holding you can't guarantee the order"

So all you have to do is identify all the locks that your APCs
might need to acquire, and verify that they are always acquired
in the same order by all possible code paths.
(Or did I miss something, Alexandre?)

A torture test program running on a multi-CPU box might
give some warm fuzzies, too, especially if you
artificially increase the duration that locks are held by
inserting busywaits.  (That will increase the chance of threads colliding.)
- Dan