Few bugs for you to slay!

1. What is the problem with following code snippet? How will you fix it?

   			lock_entity_i
   			critical section
   			lock_entity_i
   				
   		

2. Consider there are 2 threads executing the following code snippet. Is it possible that one thread will remain in waiting state/deadlocked state forever? If yes, how will you fix the problem?

   			lock_entity_i
   			if(entity i is already copied)
   			{
   				i++;
   				unlock_entity_i
   				continue;
   			}
   		

3. Assume, given code snippet belongs to a single threaded process, inode_sem is a counting semaphore and no other process uses inode_sem. inode_sem is initialized to 1, meaning 1 process can enter critical section after acquiring this lock. lock call on it will decrement it to 0 and lock has been acquired now. If lock call is made again, its value becomes -1 which means that there is 1 waiting process on this semaphore. If lock call is made again, semaphore value becomes -2 which means that there are now 2 waiting processes on this semaphore. When first process calls unlock, semaphore value becomes -1 and one of the waiting processes is chosen to come out of wait and enter critical section and so on..

   • a) Can given code snippet enter deadlock? How?
   • b) What if this snippet belongs to a multithreaded process and all threads access this code snippet. Can given code snippet enter deadlock? How? Can critical section be entered by mutiple threads? How?
   • c) How answer to a) changes if inode_sem is a binary semaphore instead of a counting semaphore?
   • d) How answer to b) changes if inode_sem is a binary semaphore instead of a counting semaphore?

   			fn()
   			{
   				if((ret=f1()) == 0)
   					goto out;
   
   				lock(inode_sem)
   				//critical section
   
   			out:
   				unlock(inode_sem)
   				return 0;
   			}