Thanks for all the good answers. I realize that the better approach would be to use the same data structure in both threads, while having different classes.
What I am actually trying to do is:
The main thread handles the game logic and works on the resources (reading/writing them). The auxiliary thread handles the display only, reading only from the resources.
I want at a later point to be able to either have the render thread:
1. either read from the original data while the game logic thread waits (thus avoiding copying the resources at all).
2. either read from a copy of the original data, while the game logic continues its work.
In case 2 above, copying the resources will be done as a light copy first (i.e. actually sharing the resource until the point where the main thread modifies it: in that case, the main thread will first deep-copy the resource before modifying it, while the render thread will still read from the old, unmodified resource, thus avoiding a crash).
Why do you have a separate thread for Rendering? Is the Rendering phase a bottleneck in your program? What happens if you simply render all your object within the main game loop?
Basically, are you sure what you're doing is worth the trouble? Multithreaded programming can be difficult to do correctly, and if you miss 1 thing, you'll start having odd bugs that are very hard to debug. Be sure you really need to do it before trying to do it.
If it's as an exercise, then disregard, but if it's a solution to a bigger problem (like making a game), then I'd re-evaluate and ensure it's really needed.
FWIW, in my hobby games I've written, I've never seen the need for more than 1 thread. Some big games will need more, but they have to have good reasons for them.