Since the clipboard is a shared resource, you need to be very careful. It is indeed very likely that the operation in thread1 will be preempted by thread2. You should be able to use critical sections to get around that, but... you need to consider that other applications on the system are also involved, in ways that are hard to predict. Other clipboard listeners will be doing their thing, possibly pasting the data into themselves, or opening the clipboard to "peek" at the contents. This will foil your attempts to quickly copy/paste data, as you will probably need to wait 1000ms or so, after copying, before you can reliably paste it. You need to consider what's going to happen if the user has a clipboard extender running (you will be filling it up with your crap). How about remote desktop? You will have to wait for the clipboard sync across the network, which in some cases, means that you could have yet another set of clipboard monitoring applications eager to examine your clipboard data, before you get a chance to paste it.
Then consider the fact that the clipboard is intended for the user's convenience, not as a crutch for the programmer.
If you continue along this path, you are surely doomed. It's a bad idea, and impossible to implement without causing collateral damage. You should re-think your design. And no, I do not have any better ideas.