The house analogy is excellent for getting across the concept of synchronization, but it falls down in one major area. In our house, we had many threads running simultaneously. However, in a real live system, there's typically only one CPU, so only one thing can run at once.
So far we've talked about scheduling policies and thread states, but we haven't said much yet about why and when things are rescheduled. There's a common misconception that rescheduling just occurs, without any real causes. Actually, this is a useful abstraction during design! But it's important to understand the conditions that cause rescheduling. Recall the diagram Scheduling roadmap (in the The kernel's role section).