Think of cpu cores as vans. Think of threads as people. Think of jobs as parcels.
Person 0 is the manager. The Game Logic thread. Thread zero.
I can have 50 parcels/threads going out today but only 4 vans. The manager always wants one van. He runs the show.
The manager can deliver most if not all on his own. When he cant, you need to start delegating your team. Never let the manager get over worked, that’s the key, and be careful with employing 500 team members with only 3 vans to use. Better to employ two or three to deliver all in an orderly and efficient fashion. Your manager is earning his pay. And not forgetting that others can’t modify other parcels without permission, etc… and so on.
I mean… that’s about as simple as I can explain it. I hope that helps you understand the complexities of multithreading.
If the dust hasn’t settled too much, I think each thread wants 1mb on the heap or some crap. It gets technical after my little story
Much like the others here I’ll reiterate what they’ve said and give you some examples as to how the game could change things.
You really need to decide on what sort of game you’re making. That’ll define a lot of how you’ll handle users.
For instance. First Person Shooter: All players interacting and firing in a single map all at once. Most likely you’ll be doing 1 thread per user in this case since they’re all doing things at the same time. But you’ll need to decide how to coordinate information between all of them since 1 character won’t just know where the other character is.
Turn based game (Civilization for instance): Although having a game of Civilization that included thousands of players would require amazingly patient players you’d probably do this in a single thread. Since you’re only handling 1 players moves at a time.
The above WILDLY simplifies what is involved but at least you can start to see where things can and will get complex.
I think an FPS is even less likely to be one thread per user because there will be a single physics thread (at least per zone) handling the physics.
Architecture matters a lot… more often than not, threads run in a different direction that a thread-newb thinks they will. ie: rather than giving one thread to each user, you give one thread to each distinct process… like in an ES, one thread per system. Networking gets two, physics gets one per zone, AI gets one, etc… or you pool them in that way.
Making sure some position updates gets where it’s supposed to go doesn’t necessarily require a thread on its own.
This may sound a bit weird but you’re asking the wrong questions to get to the end result that you want.
From what I can gather you’re trying to make an MMO of some sorts. This is not a small undertaking by any stretch of the imagination but I wish you good luck and I look forward to seeing what you make! The memory stuff you bring up is something to be concerned with once you get to that point…
However…
You’re not at that point yet.
When it comes to making really big projects (or any really) it’s usually better to tackle the core features of what it is you’re making first… And make it efficient second.
If I were to order your project it’d go something like this.
Make a super basic version of your game playable
Make your game playable by a small group of people simultaneously
Polish your game so it’d be something people would DEFINITELY want to burn hours and hours at
Build a community
Source a place to host this (Your home is not going to have a big enough internet connection for that sort of scale)
Make your game playable by the thousands.
Notice that the questions you’ve asked though address points 5 and 6 more than anything. You should really start working on #1 more than anything else.