Q.1 )	What is "Hashtable<ThreadCB, RRB> threadRRBTable", and what information do we store in it ?

A.1 )	Think of it as a table, where we store requests made by threads. It contains an entry for 
	every live thread (created but not killed yet), and the value for that entry is a RRB object
	which holds a pending request made by the thread. So this data structure basically holds the
	information of the request matrix (similar to need matrix in deadlock avoidance).

	eg. If the request matrix looks something like the following (where A,B,C,D are resource types)

					A	B 	C	D
			thread 1	0	0	2	0
			thread 2	0	1	0 	0
			thread 3	0	0	0	0
			thread 4 	0	0	1	0

	Then our threadRRBTable will have four entries, one for each thread. The entry for thread 1, will 
	have a RRB object which holds the information "thread 1, has requested 2 instances of resource C",
	and we will have similar entry for thread 2, and 4 as well. But since thread 3, does not have any
	pending requests, we will store nullRRB for thread 3. Note that we’re using a Hashtable because our
	threads don’t have nice numbers as above. This way you can pass the Hashtable the ThreadCB Object and
	get the ResourcesCB and quantity back.

	Whenever the request of a thread is granted we replace it's entry with a nullRBB (usually when some other threads
	release resources). And whenever a thread is killed we remove it's entry from threadRRBTable, we do it in the 
	do_giveupResources (Q.10) method in this project.

Q.2)	It looks like a thread can make a request for only one resource at a time, am I right ?

A.2)    Yes, in OSP's implementation a thread can only request instances of one resource type at a time. 
	That is why storing only one RRB object against a thread suffices. If you see the example from the previous
	question you will find the row corresponding to every thread has at most one nonzero entry.

	If the request is granted, it can make another request. But if not granted the thread is suspended and cannot
	make any request until the pending request is granted.


Q.3)	Where can I find information about how many resources do we have? What are the resources do we have ?

A.3)    Information about a particular resource type is stored in corresponding ResourceCB object. We can find references
	to all such ResourceCB object from ResourceTable. So if we want to iterate through all Resource type we can do 
	something like the following

	int nResources  = ResourceTable.getSize();
    	for( int i = 0 ; i< nResources ; i++){    		
    		ResourceCB ithResource =   ResourceTable.getResourceCB(i);     				
   		
    	}  

Q.4)	Ok, but for deadlock detection, I need more information, the information stored in Allocation matrix and
	Available vector. How do I get them ?

A.4)	Provided we already have the ResourceCB object, we can know how many instance of the resource is available by
	invoking the resourceObject.getAvailable(). And if we want to know how many instance of that resource a particular
	thread has allocated, we can find out by calling resourceObject.getAllocated(thread).

Q.5)	For deadlock detection, the assignment mentioned about Work[] array ? How to initialize it, how do we know 
	how big is it? how do we copy current available amount in to it.

A.5)	Work[] should initially have the available amount of each ResourceCB type in it. Specifically, Work[i] should
	contain the number of available instances of Resource with ResourceID = i. We can do it like the following

	int nResources  = ResourceTable.getSize();
    	int Work[] = new int[nResources];    	
    	for( int i = 0 ; i<nResources ; i++ ){
    		Work[i] = ResourceTable.getResourceCB(i).getAvailable() ;
    	}

Q.6)	Well, I have a ResourceCB object, but I do not know what index of my Work[] does it correspond to.

A.6)	resourceObject.getID() gives you the corresponding index.

Q.7)	What about the Finish[] array, how do I know which thread correspond to what index of it.

A.7)	Remember that your Finish[] array just keeps track of threads you have marked off as “ok” or not deadlocked. You can implement your Finish[] array as boolean or by using an integer variable set to 0 or 1. Then you will want to iterate through the threadRRBTable while simultaneously keeping track of the index for finish
	are iterating the threadRRBTable like to following.

		keys = threadRRBTable.keys();
    		int threadIndx = 0;    		
    		while(keys.hasMoreElements()){
    			ThreadCB cThread= keys.nextElement();
			if( Finish[threadIndx] ) {
				/* Do what you do if you have set this to true
			}
			/* More code here */
			threadIndx = threadIndx + 1;    				
    		}    		
	
	Notice that threadIndx is the index of cThread in Finish array.

Q.8) 	Can I use other data structures for Work, and Finish instead of array? Say for example hashtables?

A.8)	Sure - Given you know what you are doing. However, simpler is usually better when writing code.

Q.9)	Since do_release, and do_giveupResources and have some common functionality, the assignment suggested to implement
	that as a separate method. I don't know how to do that. Can you help me?

A.9)	You may have a method with the following signature, which performs the functionality of releasing 'quantity' instances of the resources allocated to thread 'thread'. 
    
		public void releaseResources( ThreadCB thread, int quantity){
		/*

		*/		
		}

	And you can have another method like the following

		public static void satisfyPendingRequests(){
			/*

			Iterate through the threadRRBTable, and for every pending requests ( not nullRRB ) check if the
			request can now be granted. If yes, grant the request, and put nullRRB in the appropriate position
			of threadRRBTable.

			*/

		}

Q.10)	I am having issues with do_giveupResrouces method. Which resources should we release ?

A.10)	In this method you have to release everything the thread has been allocated with, it might be from any resource type. So in general you might have to do the following.

	1. Loop through every resource in the ResourceTable (Q.3), and for each resource release the allocation of the thread( passed as parameter)
	2. Remove the thread from threadRRBTable.
	3. Try to satisfy any pending requests (Q.9). 


Q.11)	I am getting the error "Your deadlock recovery has killed Thread(86:3/KL) unnecessarily, since it was not deadlocked"

A.11)	You can get this error for a number of reason. One of the reason is as follows:	
	For being in a deadlock, a thread must hold and wait. That is, a thread which is not allocated with any resources cannot be in a deadlock. You have to check this condition,
	possibly at end of the method you wrote to identify deadlocked thread.

Q.12)	When do we add RRB's to the threadRRBTable ?

A.12)	We add them in do_aquire method. Based on if the requested amount is available we may have something like the following at the end of do_aquire method:

	if( requested amount is available ){
		1) grant the request by invoking grant() on the rrbObject we created earlier
	} else if ( current thread is not waiting){
		1) Add the rrbObject to the threadRRBtable against the current thread. e.g threadRRBTable.put(currentThread , rrbObject )
		2) Change the rrbObject status to Suspended
		3) suspend the current thread with RRB object as argument to suspend method.
	}

	return rrbObject