Physics has nothing to do with graphics, so certainly don't put it there. Really, physics is its own subsystem. It takes inputs from game logic (forces to insert into the system) and generates an updated game state (and generates messages for collision updates).
For integration, it's common to have something like:
game loop:
pump events
update input
update AI
update physics
render
The physics update can generate events during collisions so that AI and other game logic can respond to them if appropriate (either by dispatching them immediately or putting them in a buffer for next frame) like triggers or falling damage or whatnot.
It's a huge fallacy to think that each component of the game should get its own thread. A game engine is inherently a serialized beast. If you have 3 systems and put each on their own thread you'll still be massively under-utilizing a 6- or 8-core system, and not even making benefit of the more common 4-core systems. Use a job system instead. Run the system in serial but have each system spawn multiple jobs (handled by a thread pool) to complete its work. Done right, each system scales up to the number of cores in the computer. Some systems demand their own threads for latency reasons (audio processing, networking) but the meat of the simulation benefits more from having many-thread-scalable individual systems rather than a parallel engine design.