So what I would like to know is when the thread scheduler performs a context switch how is the CPU interrupted so the task of switching over to a different process gets accomplished? Does the CPU get paused or go into sleep mode while the new context loaded onto the CPU ?
It actually is "interrupted," in the true sense of the word.
The CPU never "pauses" during a context switch. It's actually quite busy doing the switch. The context switch starts when a timer interrupt is triggered. Virtually every CPU in existence has a configurable timer that triggers an interrupt when it goes off.
When an interrupt is triggered on a CPU for any reason, the result is that the CPU looks up a specific memory address, which is the "interrupt vector" for that interrupt. This is a table of addresses, one for each interrupt that could occur (there is a small number of them, so this table is not huge). It simply says that when the interrupt occurs, the next instruction is whatever that address is. It stops running
This address is the address of an interrupt handler or interrupt service routine (ISR), depending on who you talk to. This is a very specialized function which obeys some very strict rules in order to be able to function right on top of any arbitrary stack. In the case of this handler, it calls the scheduler, asking it to do a context switch.
The scheduler is also designed very carefully to allow one to save off the "context," which includes things like IP addresses, stack configuration, registers, and virtual memory layouts. It then chooses a thread to run next, loads up its information, and finally sets the IP address to where it left off last time that thread was suspended.
This process is very busy for the CPU. It is anything but idle. In particular, it has to flush many architecture-specific caches, which account for much of the latency one sees which switching contexts.