This assignment is based on sample code from Eli Bendersky. He has a blog post that discusses it: https://eli.thegreenplace.net/2019/on-concurrency-in-go-http-servers/ and the code is found on github: https://github.com/eliben/code-for-blog/blob/master/2019/gohttpconcurrency/mutex-se rver.co On github, you can click on the Raw link to see the plaintext of the code. I'll mention several of the points he makes in the following. In this assignment, you will: Here are the requirements: Get a deeper understanding of interacting with web services Get practice with synchronizing multiple threads First, build and run the existing code. Note: the default port number used here is 8000. A student had a problem on the previous assignment where some setting on his computer was blocking attempts to use 8081 as a port number and would only accept 8080, so if things don't run, try changing 8000 to 8080. 1. I think the most important takeaway from Bendersky's blog is that even though you do not see any goroutines here, a web server is running things concurrently so that multiple users could interact with the server concurrently and not get bogged down waiting their turn. 2. An interesting thing to note is that the sync.Mutex field of Counter Store is just by itself. This is a feature of Go that lets you do composition conveniently. Ordinarily, you would define a field of type sync.Mutex, but every time you wanted to call Lock() or Unlock(), you would need to write something like "cs.field.Lock()". The existing syntax lets Benderskx write "cs.Lock()", so it's as if Counter Store has inherited the functionality of Mutex but without the potential problems that we discussed for inheritance of implementation. 3. There is also a nice use of the defer command here to ensure that the lock is released in all cases after one of the functions that affects the counter is done. Now modify the code so that it manages Account's for a payment processor (a bit like Paypal). We'll say a bit more about the more likely approach that such a program would take, but this is to motivate the concepts of synchronization. 1. An Account is a struct with an owner(string) and balance(int) 2. Using *Account as a target, add methods to get the balance, set the balance and modify the balance 3. Update the rest of the code so that Counter Store is now Accountstore and maps strings to *Account's. The strings become the account ID's One thing we note is that there is just one lock for the whole map. This is ok for the simple example being presented, but it does block one user from incrementing pointer A when a second user is incrementing pointer B, even though the two pointers are not related. 1. Move the Mutex to the Account structure 2. Note that we cannot use the composition feature anymore. That would imply there is only one Mutex for all accounts and we would not be gaining any greater concurrency. Create a named field of type sync.Mutex Add support for a /pay endpoint, 1. The (required) parameters are: 1. from (string): account ID of account where money will be taken out 2. to (string): account ID of account where money will be deposited amt(int): amount to transfer 1. Protect this transaction by locking the two accounts and unlocking them appropriately. Note that if you forgot to name the Mutex field, you will not be able to execute the transfer since the code will try to lock the same lock twice. 2. As a minimal error handling requirement, make sure that there is enough money in the "from" account to make the payment. Produce an error message saying so if not. 3. Once you get this all working, you can go to a browser and enter a URL like the following to make a payment http://localhost:8000/pay?from=A&to=B&amt=20 Submission: It's just one.go file.