Modifier and Accessor Synchornization

Question

Hi,
This is not what you may think -- it is not about getter and setters, allow me to elaborate. I have a data structure that requires a few modifications to the underlying data and many accesses (M threads add/remove, N threads access).
To achieve concurrency, I am adding two minimalistic locks to synchronize between two thread types. One for when the data structure goes under modification phase (modifyingLock) and one for the count of threads currently accessing the data structure (threadCount).
The premise is allow modifying threads to make modification to data when there is no thread accessing (reading) it. Therefore, it must wait until all the accessing threads are done by verifying whether threadCount is zero or not. Ergo, Access threads can be in two states, either in process of accessing the data or just about to begin searching. In case of former, the accessing thread should be allowed to finish it search and at the end decrement threadCount. If the thread of type N haven't begun accessing the data and see modifyingLock set, they should wait until modifications are perform to data and get notified upon completion. The process should work as following:
Modifying threads (M),
- Before making any modification, M must check to see whether modifyingLock as been set which is an indication another M thread is (OR about to) making modification to the data structure and also check whether any thread of type N is accessing it.
- If either condition is not met, threads of type M must wait until either another thread of type M finishes its task of modification and/or accessing threads of type N are flushed and done with their search (threadCount should be zero).
Accessing threads (N),
- If modifyingLock is not set, they can began accessing the data structure safely knowing thread of type M would not begin its task of modification until all the accessing threads are done.
- And any further new access would be blocked and have to wait until thread M's are done with their task.
Sounds logical but when it comes to the actual implementation, I can clearly see that there are many possible thread locks which I cannot seem to figure how to remedy:
// Partial code of add() method
// modifyingLock is a byte[] of size one
// threadAccessCount is an int[] of size one
    synchronized (modifyingLock) {
        while (modifyingLock[0] != 0 &&
                threadAccessCount[0] != 0) {
          try {
            modifyingLock.wait();
          } catch (InterruptedException ie) {         
        } // end of while loop
        modifyingLock[0] = (byte) 1;
        // Actual modification to the data structure
        modifyingLock[0] = (byte) 0;
        modifyingLock.notifyAll();
    } // end of synchronized block
// Partial implementation of accessing method
    synchronized (modifyingLock) {
      while (modifyingLock[0] != 0) {
        try {
          modifyingLock.wait();
        } catch (InterruptedException ie) {         
      } // end of while loop  
    } // end of synchronized block
     synchronized (threadAccessCount) {
       threadAccessCount[0]++;
    // Actual search or read task
    synchronized (threadAccessCount) {
      threadAccessCount[0]--;
      if (threadAccessCount[0] == 0) {
        synchronized (modifyingLock) {
          modifyingLock.notifyAll();
    }Now my question, can you come up with any scenario where a deadlock or race condition can occur?
Thank You

Answer 1

Maxim_Karvonen,
Thank you for the keen eyes; I really didn't except anyone to read through the whole thing. I can swear I had made changes on my last reply that should reflect many of the issues you pointed out. I don't know why my last post does not reflect these changes. In any case, let me recap what the requirement for my problem is as it'll help explain the situation become more pristine.
We have writer and reader threads which both work on the same set of data structure. Since there is a mutual underlying data involved, I was hoping to come up with a mechanism to basically flush out the "reader" threads as soon as a "writer" thread appears for a modification to such data structure. And by flush, I am not saying to terminate the search in the middle of work but rather allow the "reader" threads to finish their task but any "new" coming "reader" AND "writer" thread must block and wait for the first "writer" thread to perform its duty.
The reason reader and writer threads may go head to head is because the modification methods (i.e. add() and remove()) both take advantage of the accessing method (i.e. contain()) to make sure an entry/node is present in the data structure before proceeding to the actual job. So as you can see, both reader and writer threads call upon contain() method at some point. Therefore, in the design, I have to make sure that all of its content only be available to a single "writer" thread.
Since my last reply, I managed (hopefully) to accomplish this to some extend. But soon after, I realized that my design would continuously only allow the "writer" threads to obtain the locks IF there is a writer thread present in the queue at any given time.
For instance, if I have 50 reader threads in the middle of contain() and 5 writer threads, waiting to be processed, all 50 reader threads must finish their task and exit. Meanwhile any incoming reader (or/and writer thread) must be blocked. Once all 50 reader threads egressed, one of the 5 (or + any incoming writer thread) writer thread is selected and given a way to perform its task.
Now, we can have two scenarios, one being to continue blocking all the incoming reader threads (which can add up to dozens by the time a writer thread finishes) due to the fact that we still have other writer threads. Secondly, allow a contention among reader and writer threads and see who wins. BUT... Due to my design, if a reader wins, then all other readers must be processed and their counter decremented to zero so the writer threads can be given a green flag for operation. And since number of reader threads pretty much dominates throughout the life cycle of the application, it will be a long epoch until any of the writer threads come to life.
So to combat this, I introduced a reader/writer ratio. Every time a writer performs its task, right before it exits, it checks to see whether a threshold has been reached. If not, it gives priority to another writer thread to continue executing until number of reader to writer threads passes such ratio. In that case, the ball would be in reader threads' court. So this is what I came up with so far:
private byte[] modifyingLock; // An indication that a writer thread "wanting" to do some work
private int[] accessThreadCount; // Number of "reader" threads
private short modificationThreadCount; // Number of "writer" threads
private double accessToModifyingThreadRatio; // The ratio of reader to writer (usually 10 to 1)
// add() method
synchorinzed (modifyingLock) {
  modificationThreadCount++;
  // An indication to all "reader" threads that a "writer" or "writers"
  // thread(S) has joined a party and everyone needs to clear out a way
  modifyingLock[0] = 1; /* (1.1) */
  while (accessThreadCount[0] != 0) {
    try {
      modifyingLock.wait();
    } catch (InterruptedException ie) {         
  } // end of while loop
  // We have to reset the lock's value because add() needs to call on
  // contain() and if we leave the lock's value on line "1.1", then
  // a writer thread that calls contain() would also go on a block
  // and create a deadlock
  modifyingLock[0] = 0; /* (1.2) */
  // If the item is already in the data structure, just return. But before
  // doing so, a writer thread needs to do some cleaning and synchronization
  if (/* contain() */) {
    // As we discussed, if the "current" writing thread leave this lock's value
    // unset, this would give the "reader" threads a way to execute without
    // giving a chance to "writer" threads.
    // This is due to the fact that the only way reader threads "know" whether
    // a writer thread is about to do some work is to have this lock's value
    // set which lets the incoming reader threads know that they should block
    // ... for now.
    // If ratio of reader threads to writer thread exceeds a certain number,
    // then the lock's value is left unset so now, "reader" threads can execute
    // their task. Otherwise, we let the next possible "writer" thread to take on.
    // This is more like a writer thread vouching for another writer thread
    // comrade.
    if (/* threshold is NOT reached */) {
      modifyingLock[0] = 1;
    modificationThreadCount--;
    modifyingLock.notifyAll();
    return;
  /****** Do the actual insertion *******/
  // This is the end of the line for the writer thread so it has to perform
  // the same set of procedures as I just described above. I could always
  // modularize it to avoid code duplication but we leave it like that for now.
  if (/* threshold is NOT reached */) {
    modifyingLock[0] = 1;
  modificationThreadCount--;
  modifyingLock.notifyAll();
// contain() method
synchronized (accessThreadCount) {
  accessThreadCount[0]++;
// If the modifyingLock is set, this is an indication that a writer
// thread is about to make a modification and all the incoming reader
// threads (those which have not begun accessing the underlying data
// structure) would have to block
// A writer thread that gets to this point has already acquired a lock
// so it follows through and also has the modifyingLock reset at line
// 1.2.
synchronized (modifyingLock) { /* (2.1) */
  while (modifyingLock[0] == 1) {
    try {
      modifyingLock.wait(); /* (2.x) */
    } catch (InterruptedException ie) {
  } // end of while loop
} end of synchronized block
/******* Do the actual search *******/
// If this is a reader thread, try to acquire a lock on the object,
// decrement the "reader" thread counter. If the counter has reached
// zero, automatically call upon any waiting thread on the lock.
// The notification is only good under two conditions:
//   - Only "reader" threads been performing and a writer(s) is on
//     a waiting list.
//   - Other reader threads that have been blocked on line 2.1
synchronized (modifyingLock) {
  synchronized (accessThreadCount) {
    accessThreadCount[0]--;
    if (accessThreadCount[0] == 0) { /* (2.4) */
      modifyingLock.notifyAll();
  } // end of synchronized (accessThreadCount)
} // end of synchronized (modifyingLock)
return /* base on the outcome of search method above (2.2) */
///////////////////////////////////////////////////////////////////////////Ok, so this might not be the most crisp design for such requirements but I think it can hold its own. One concern that I have is that during the work flow of a "writer" thread, when it is about to exit contain(), it "might" call on notifyAll() once here, and another time at the bottom of add(). Would that be a problem? Note that the lock on the modifyingLock is still held by the writer thread up to the end of add().
Another tiny problem that I can think of is when contain() method returns at line (2.2). This is a clear case of unsafe "compound" actions which can result in some reader getting all the way down to line (2.2) and a context switch occurs. As a result, a writer thread begins working (and ultimately exits). In that case, a return value of true may well be "false!" due to alteration done to the data structure. This could leave a client of reader thread very unhappy. Although, this scenario can be very unlikely, it could happen and I do not know how to resolve it.
I still have to think about a few pointers. Maxim_Karvonen, I would like to extend my gratitude for your participation in this discussion. If it wasn't for your reply, I wouldn't have cared to post this latest response. I know this might not be the end so I keep digging.
Thank You