In a multitasking operating system the OS does not have to do anything as extreme as outright stopping the processor from running at all or filling the time that that process was going to be using with other instructions. It can do something infinitely simpler. It can simply not schedule the task to be run at all.
This is the whole point of a multitasking operating system. If multiple tasks all need to run at the same time then the OS swaps one onto the processor, lets it run for a period of time, then swaps the next task in and carries on until all the tasks that need to run have done their jobs.
When a task signals that it wants to sleep for a period of time or to wait for a keypress what it is effectively telling the operating system is don't bother swapping me onto the processor unless time X has passed or don't bother running me unless you have event X waiting for me to action it.
Basically the OS has a long list of tasks that need to run, and against each one would be a "waiting for event" descriptor. Any tasks that are ready to run would be able to be scheduled and any that are not would simply be skipped, simple as that.
If there are literally no tasks at all to run on the processor in a particular time slice then the operating system schedules an "Idle" task which will actually HaLT the CPU and tell it not to execute instructions until it gets woken up, usually by an interrupt of some sort. Using this method of scheduling time to "do no work" fits in well with the paradigm of a multitasking operating system as well.
In order to wake up again the CPU gets interrupt "ticks" via the RTC (real-time clock) and additionally can set up the HPET (High Precision Event Timer) to fire an interrupt at a specific time interval. This allows the OS to halt the CPU for very precise lengths of time and then kick the CPU out of sleep to begin processing tasks again.