Should we assume both processes are getting same CPU clock while we solve SYNCHRONIZATION problems in uniprocessor system?
It is very common to run processes on an operating system with a preemptive scheduler. The scheduler can switch between processes at any time: it is unpredictable when the operating system will switch from one process to another.

Unless otherwise specified, this is the model we use when discussing synchronization problems: there may be a switch between processes at any time. This means that in many cases there is no difference between the uniprocessor case and the multiprocessor case: the same execution sequences are possible in both. The operating system effectively pretends that there's one CPU per process.

The switches can even happen in the middle of a high-level instruction. For example, if you write a simple assignment in a high-level language

x := y;


this could translate to multiple machine instructions such as

copy top half from x to y
[possible switch]
copy bottom half from x to y


or

load x to register r1
[possible switch]
store y from register r1


This is why it's important to know which operations are atomic even in the uniprocessor case.

When you consider synchronization between kernel threads, and you get down to the level of machine instructions, there are things that are not possible in a uniprocessor case, because the kernel decides when a context switch is possible. But to exclude these impossible sequences, you need to know both how the machine instructions work and how the kernel works. If you don't know that then you can't exclude any interleaving of the execution.