What is the backbone of your game? What is the structure? This is purely a game logic issue and should have no effect on threading, rendering, etc. as long as you have a clear idea of your game structure.

In my personal frameworks, I implement this sort of thing using some sort of timer class. Say your trajectory and ballistics calculations indicate that the optimal time to fire will be 2 seconds in the future, given the target's current velocity. That means the entity doing the firing needs to go into a suspended state. Of course, all the other entities shouldn't be suspended just because one is. So what I typically do is register a Timer with my central control mechanism for 2 seconds, and set up the entity to listen for the event that gets triggered when the timer expires. Each time through the main loop, all existing timers are decremented by the time step, and any that go below 0 are caused to transmit their signals and removed from the list. Considering that the backbone of my game is a message pump, it is easy enough for an expiring Timer to transmit a message through the pump targeted at the entity that wants to listen for it.

Note also that your entity logic should be intelligently structured so that the entity doesn't become locked in his waiting state. Say the target switches direction, requiring new calculations and a new timer. You need to be able to cancel the old timer and instantiate a new one. Or say, while your entity is waiting to fire another opponent ambushes it from another direction. The entity needs to be able to react appropriately to this new change in priorities, canceling the timer on his optimal shot and entering a defensive state. So the suspend state shouldn't be anything so crude as a busy-waiting while loop or thread, but instead just an AI state dependent upon the appropriate set of control and environmental factors.

Edit: Reading your post a second time, it seems that making the shot isn't the question, but waiting for the shot to arrive is. But, again, what I said applies: this is a timing issue (possibly even a collision one) rather than a threading or busy-wait issue. When the bullet arrives at its target (or collides with anything at all) it will transmit a signal through the central event system to the affected object.

Resolved by creating a timer class, I'm wondering if it's a good idea to make the timers class work on a separate thread for better performance.

Profile first to see if it's a bottleneck. (Note that it almost certainly won't be, unless it's doing something stupid; the computing going on in a timer class will be trivial.) Simply making something multi-threaded isn't necessarily a magic bullet to make things faster. I typically reserve multi-threading (if I even use it; I have yet to make a game intensive enough that it is actually necessary) for heavy tasks: background streaming of data, maybe some AI, things that can largely be done in great chunks in relative isolation, since interleaving of access and communication between threads can complicate the process. Decrementing a few timers and passing on signals just isn't the kind of computing- or memory-access-heavy work that would necessitate multi-threading, in my opinion, making any gains from the effort minimal at best.

In short: don't complicate your code unless you absolutely have to.

@ankhd: In real life, a bullet should take time (in milliseconds) to arrive to the target depends on it's speed and how far is the target.

Of course, you can also simulate that by giving the bullet an appropriate velocity when it is spawned. No need for a timer at all.