Currently most of dbms imploying that kinda greey logic
that take the lock for atom. (For example,
if, there is few hundreds of requests from multiple and concurrent location to
one single record to insert/update/alter what every concurrent. This situation only allow to get the lock for an user when only luckly reach the record. which mean very randomly can get a lock.) This situation make problem hard to solve.
So strongly suggest you to improve deadlock problem which go down in history,
manage lock request as FIFO in order and give the lock in sequence/arrival order.
Fro example,
no1. request insert
no2. request update
no3. request select!
no4. request select
no5. request alter
no6. request select!
no7. request delete
no8. request another alter
no9. request select!

each of request will be arraived in the db system in order(sure, system-wise, there is no real concurrent) and must be applied in sequence. Not greedly make rece condition that today's unresolvable problem. The semapore or mutex or whatever lock mechnism will be totally redesigned to beFIFO managed without performance impact.
It also has to be turn-of/off by config. default off.