Original Post
So after a number of rousing talks at GDC, I decided that it'd behoove me to learn a little about multi-threading. I've read some articles and posts, and think (or rather, thought) I knew enough to begin striking out on some architecture for some trial-by-fire attempts. I decided to start with a simple application in order to wrap my head around the architecture needs: a tcp/ip chat client. So there are four basic structures to a chat client server: Listen for new connections, read incoming data, process the information, send outgoing data. Easy enough, so then I got to designing architecture. An obvious first approach was Functional Threading; one thread for each task. But that doesn't scale well, so I scrapped it. Much nail biting later, I happened upon the concept of a Job Queue. One Foreman (a monitor) who controls a bunch of Workers (threads, one for each core), each of whom pick away at Jobs (parallel-able task functions) in the Job Queue. Basically a completely parallel structure. Just keep adding Jobs to the queue, and they'd get done eventually by some Worker. 
But I didn't really feel comfortable with the notion that there is no level of "This-before-That", so I added a little mod to the structure. Using the same Foreman/Worker/Job model, I applied it to each of the main systems instead. First the Read-Incoming-Data Foreman would hire Workers to process all the Read-Incoming-Data Jobs, then it'd wait until all the Jobs were finished before halting that Foreman and letting the Process-Information Foreman take over, etc etc. This version does scale well, and it does keep login in-line (which makes it easier on my head), but it's far from perfect. Really, at this point, any comments or a point in the right direction would be helpful. What's wrong with my design? What's right? How do I deal with Jobs that need to be run at a certain frequency (like rendering)? I don't want to use pre-made code, since I'm learning architecture, not APIs, but examples or explanations of what other, more experienced multi-thread programmers have done would do me well.
But I didn't really feel comfortable with the notion that there is no level of "This-before-That", so I added a little mod to the structure. Using the same Foreman/Worker/Job model, I applied it to each of the main systems instead. First the Read-Incoming-Data Foreman would hire Workers to process all the Read-Incoming-Data Jobs, then it'd wait until all the Jobs were finished before halting that Foreman and letting the Process-Information Foreman take over, etc etc. This version does scale well, and it does keep login in-line (which makes it easier on my head), but it's far from perfect. Really, at this point, any comments or a point in the right direction would be helpful. What's wrong with my design? What's right? How do I deal with Jobs that need to be run at a certain frequency (like rendering)? I don't want to use pre-made code, since I'm learning architecture, not APIs, but examples or explanations of what other, more experienced multi-thread programmers have done would do me well.