First of all, using a thread per entity (talking about OS threads here, not language specific cheap co-routines) is insane. A thread is expensive, for example it needs a stack which by default uses 1MB of address space. Thread switching is expensive costing thousands of CPU cycles.
I wouldn't use multi threading at all in your main game logic. It adds a lot of complexity. First write it single-threaded and later perhaps multi-thread some hot-spots like path-finding and collision detection.
Tim Sweeney[The Unreal Engine guy]: For multithreading optimizations, we're focusing on physics, animation updates, the renderer's scene traversal loop, sound updates, and content streaming. We are not attempting to multithread systems that are highly sequential and object-oriented, such as the gameplay.
Implementing a multithreaded system requires two to three times the development and testing effort of implementing a comparable non-multithreaded system
From http://www.anandtech.com/show/1645/3
Just iterating over all entities is usually fast enough. You'll have a few thousand of them, so iterating over them by itself takes fractions of a millisecond. Benchmark first before worrying about such stuff.
When I wrote an RTS (which from the technical side is not that far from a tower defense game) the top performance killers with a naive implementation were:
- Collision detection, you need to use some spatial partitioning to make this fast.
- Pathing can be very difficult, depends on your demands and the topology of your level
- Finding opponents in firing-range. Once again needs spatial partitioning. And in my experience separate partitions for different factions are a must(you have many friendly units in firing range typically, but few hostiles). Locking on to a target, once you found one, until it get out of range/dies saves a lot too, since you don't need to search again all the time.
The cost of simple looping and local entity behavior typically pales compared to these few expensive tasks.
