That is a great idea to try for anyone willing to give it a go. I've done multi-thread coding myself but not in C++. Only in FreePascal.
The only possible hiccup is that no where have I read DarkGDK as being threadsafe.
This MIGHT Mean that it would choke terribly if you did this without syncronization.
Basically, I've been able to make SOME things that shouldn't work with multi-threading work and sometimes its impossible.
Plausable #1
The trick MIGHT BE to Make the SYNC thread set a Global Boolean to TRUE whenever it knows its ABOUT That Time to Call Sync Again. then your main loop would set another Global as OK GO. Then your main program would loop on Sleep until a third Variable from the sync side said All done.
You need separate variables for each step so there is minimal "collision" otherwise you need Serialization code.
More Plausible #2:
Multi-threading is great but it has overhead. Your CPU executes more commands then you think inorder to switch tasks - and it does this constantly. Put Old MS-DOS on a Pentium 4 and see what speed really is! Anyways, the idea of looping and only syncing when 16.6 milliseconds has passed (or more) makes more sense and gives your CPU more time to work on your game versus taskswitching. Also, this method would help on a superfast machine and on a slower machine would act like it wasn't even implemented because every loop it would have been enough time for another sync anyways.
I'd go with this method. 100 FPS is sweet.. but the whole human eye thing.... besides - If you get 200 FPS... you need to consider adding more stuff to your game anyways!