Lock Modes

The beginning of a brave attempt to understand locking in detail. Let us start with lock modes:

Share Lock (S)
The lock owner can read the object but cannot modify it. Other concurrent processes can obtain a Share Lock or an Update Lock (one of them) on the same object. No one else can get an Exclusive Lock though.

Exclusive Lock (X)
The lock owner can read, change or delete the object. Other concurrent processes cannot get any lock on the object and have to wait unless they are running in Uncommitted Read mode. Sometimes, if lock avoidance techniques are used, other concurrent processes may be able to read committed data (not sure how yet).

Update Lock (U)
The lock owner can read the data and intends to update it in future. Other concurrent processes can read the data but no one else can change it. Before actually making the change, an Exclusive Lock (X) will be taken on the object. If other processes have an S Lock, this can cause a wait for the lock owner.
The main reason behind having an Update lock is to prevent deadlocks which can otherwise happen between two processes which have a Share Lock on the same object and first one of them attempts to get an X lock and waits; the second process may also try to get an X lock and will wait. This will lead to a deadlock. With Update locks, this can be prevented as follows:
T1 (transaction 1) gets a U lock because it intends to update. T2 gets an S lock (which means it can't attempt to update) and can read the data. If T1 now tries the update, it will try to first convert to an X lock and this will block (due to T2's S lock). T2, however, cannot try to upgrade its lock to a U lock (if it wanted to update, it should have taken a U lock initially and can't change its mind now?). What if T2 tries to upgrade to an X lock, will that not cause a deadlock? Need to check.