That sounded like a recipe for contention.
I think because the screen "Device" is one chunk of ram when you get past the hoopla - it boils down to multi-threading for display stuff ends up needing sync anyway before each cycle/display sync.
I don't think this is where multi-threading would be really cool.
(Because all the threads would halt during the "commit" of the "screen" device" giving you actual threading work for a bit - halt - screen/sync - thread again etc... plus this scenario coupled with the overhead for threading in the first place - if not using affinity - (Selecting specific CPU's) would be counter productive - especially because each thread needs to "give up" the CPU voluntarily of they are all going to purr nicely. If your program has two threads that need to hustle, you best have them on two processors (via intel dual/quad magic architecture or literal processors)
I think if you DO have multi-processors available - and you weant to do background stuff like fetching graphics, AI that's not directly in the "close up gameplay" and stuff like that - that's cool.. and I bet you could do that in along side DarkGDK via OS calls. I wouldn't expect DirectX to multi-task well with regards to the screen and/or onscreen objects being manipulated by multiple threads simulatanteously - I think it would chug.
However I think in DirectX native - it might be something that is more doable in a multiple display scenario - two separate "device context" - I could see that working rather swell - one thread has one "display" and 3d stuff it handles and the other another.
