In 2), B is indeed signaled and the OS makes it "runnable".  But it doesn´t run immediately. A is still running.  There is no need for A to stop running until it runs out of timeslice.  Meanwhile the OS has to put B on a separate core (which makes this problem more significant on multicore), putting it at the end of the runnable queue where it has to percolate to the top for it to actually start execution some time later.

In effect, B has has to 'race' with A (and any other threads) to get the lock and since A is already running, it is likely to win the race.

Having threads 'race' to get synchronization primitives is a valid technique to reduce lock convoying problems, but it also can cause thread starvation, and is not approppriate when you want to ensure fair use of the resource.  To ensure fairness, lock "handoff" must be used.