The triggers for context switches will depend on the operating system in question.
They are no triggered by the CPU itself, but by a function call by the operating system ( or Kernel code)
This can be as the result of an event ( e.g. an interrupt from the system clock or a serial port ) or calling a system function (e.g. sleep() or write() )
The psuedo code for a system clock interrupt could be something like
incrementSystemTimers()
doContextSwitch()
and the psuedo code for the sleep system call could be something like
calcuateNextExecutionTime()
doContextSwitch()
doContextSwitch() is just another function that is something like
determineHighestPriorityProcess()
saveCurrentProcessContext()
LoadNewProcessContext()
The process context is effectively the state of the processor registers at the time the process is preempted.
The highest priority process that is ready to run is determined by an algorithm in the operating system and will depend on the type of operating system.
If there is no process ready to run then some form of idle process is selected.
The tick timer (or system clock) is programmed by the operating system vendor (e.g. microsoft)
As far as intruction timings are concerned, then normally a processor can only perform a fairly simple operation on each clock cycle (e.g. adding 2 registers together).
Multiplying two registers is normally a more complex operation where for each clock cycle one register is shifted and then added to the other register, thus a 16 bit multiply may take 16 clock cycles.
The multiply operation is controlled by 'microcode' on the processor that effectively runs a very small function
RISC processors had the design aim that they would only support simple operations, meaning that they could execute their instructions in 1 clock cycle, but complicated instructions have to be coded as any other functions would be.
Also, some processors(e.g. DSP's) have dedicated hardware, like barrel shifters than enable them to perform integer multiplications in single instructions