What is the difference between concurrency control in operating systems and in trasactional databases?
Databases have two concurrency requirements. One is the very short term physical management of memory blocks as they are referenced. These are known as latches in the DB world and can be implemented using mutexes and the like. The concern here is for the stability of a block of memory while a worker thread is accessing it.
The second controls the validity and isolation of the client data held within the DB. They control access to logical things (tuples, tables etc.) rather than physical hardware-related things (memory blocks).  These are refered to as locks. They last as long as the client transaction lasts, which can be an arbitrarily long time. The locks are typically held in a separate structure to the one which holds the object that is locked. Consequently the thing locked need not be in memory for the whole duration that the lock is held. For example, a page may be read in, a row inserted and a lock taken on it to ensure isolation. If the page containing the new row is evicted the lock would remain in effect. Indeed, the things locked may not exist when the lock is taken! A range lock protects key values from a lower bound to an upper bound. Neither of these values need be present in the data when the lock is acquired, nor must There be values that fall within the range. Nevertheless the lock will come into effect and allow isolation of clients' work.
The introductory sections of Goetz Graefe's &quot;Survey of B-Tree Locking Techniques&quot; covers these ideas nicely.
An OS deals with the first of these only (in my limited expertise). Any extension to disk is hidden behind virtual memory and the page file. In contrast a DBMS explicitly handles RAM and disk residence to optimise for its specific use-case. Different requirements lead to different treatments between OS and DBMS.