Editing Lock (computer science) (section)

===Lack of composability===
One of lock-based programming's biggest problems is that "locks don't [[Function composition (computer science)|compose]]": it is hard to combine small, correct lock-based modules into equally correct larger programs without modifying the modules or at least knowing about their internals. [[Simon Peyton Jones]] (an advocate of [[software transactional memory]]) gives the following example of a banking application:<ref>{{Cite encyclopedia |title=Beautiful concurrency |first=Simon |last=Peyton Jones |encyclopedia=Beautiful Code: Leading Programmers Explain How They Think |editor1-first=Greg |editor1-last=Wilson |editor2-first=Andy |editor2-last=Oram |publisher=O'Reilly |year=2007 |url=http://research.microsoft.com/en-us/um/people/simonpj/papers/stm/beautiful.pdf}}</ref> design a class {{mono|Account}} that allows multiple concurrent clients to deposit or withdraw money to an account, and give an algorithm to transfer money from one account to another.

The lock-based solution to the first part of the problem is:

 '''class''' Account:
     '''member''' balance: Integer
     '''member''' mutex: Lock
 
     '''method''' deposit(n: Integer)
            mutex.lock()
            balance ← balance + n
            mutex.unlock()
 
     '''method''' withdraw(n: Integer)
            deposit(−n)

The second part of the problem is much more complicated. A {{mono|transfer}} routine that is correct ''for sequential programs'' would be

 '''function''' transfer(from: Account, to: Account, amount: Integer)
     from.withdraw(amount)
     to.deposit(amount)

In a concurrent program, this algorithm is incorrect because when one thread is halfway through {{mono|transfer}}, another might observe a state where {{mono|amount}} has been withdrawn from the first account, but not yet deposited into the other account: money has gone missing from the system. This problem can only be fixed completely by putting locks on both accounts prior to changing either one, but then the locks have to be placed according to some arbitrary, global ordering to prevent deadlock:

 '''function''' transfer(from: Account, to: Account, amount: Integer)
     '''if''' from < to    ''// arbitrary ordering on the locks''
         from.lock()
         to.lock()
     '''else'''
         to.lock()
         from.lock()
     from.withdraw(amount)
     to.deposit(amount)
     from.unlock()
     to.unlock()

This solution gets more complicated when more locks are involved, and the {{mono|transfer}} function needs to know about all of the locks, so they cannot be [[Encapsulation (object-oriented programming)|hidden]].