What kind of synchronization do you want done by the thread? Are you looking to have it resume processing or stop processing (the current frame) and go on to something else?
(I'm no expert on DirectX or other graphics topics, so take the following with the appropriate amound of salt.) If there is an API call involved (DriectX), you could set up an event that is signaled just before or after the monitor refresh. The thread to be synchronized can monitor the event and sychronize when it is signaled. Use WaitForSingleObject and give it a timeout value of zero. This will return immediately with the status of the event. If the event is auto-reset, the WaitForSingleObject call will reset it for the next synchronization.
I'm not expert in DirectX either, otherwise I wouldn't need any sychronization, DirectX does it natively.
Knowng DirectX is great and I'll learn it when I'll have more time, but for simpler graphics, to me it looks like using a giant truck to carry an envelope.
The cause somebody is looking for the monitor refresh is usually the desire of getting flicker free picture changes. I don't want a refresh to occur when half of the picture is drawn.
(Double buffering greatly reduces flickering but still doesn't elliminate it totally, a refresh can still occur during that unique BitBlt form the memory DC to the window DC.)
As about the difference between resuming or stopping processing I don't think it's important, I can write code to handle any of the two scenarios.
The key issue is to have a clue about the moment the monitor refresh occur (a timer, an event, a value at a port, a function to get the timer status of refeshing, a small code to query the display adapter, etc).
I don't know about DX, but many swap_buffers implementations are synced to the monitor refresh by default. I know glutSwapBuffers() is, because I had to fight it to get that disabled when I didn't want to be refresh-rate-limited.