java spurious wakeups

What are spurious wakeups ?
In java , a thread t is put into waitset of an object 'a' by calling a.wait();
To be selected to be removed from a's waitset , there should be a call to a.notify / a.notifyAll from another thread.This is an example for explicit wake up(Which most programmers are aware of and think that this is the only possible way to wake up a waiting thread).

Note from JLS :
 An internal action by the implementation. Implementations are permitted, although not encouraged, to perform "spurious wake-ups", that is, to remove threads from wait sets and thus enable resumption without explicit instructions to do so.
Notice that this provision necessitates the Java coding practice of using wait only within loops that terminate only when some logical condition that the thread is waiting for holds.

 What it means ?
JVM implementation are given flexibility to wakeup a thread even when there is no explicit calls to either notify or notifyAll.Such wakeups, which are possible , are called spurious wakeups.

Consider the following code , for simplicity sake removed try catch blocks:

void method(){
  synchronized(a){
      if(cond / buffer empty){
         a.wait() ;
         //do some task asuming buffer is not empty.
      }
  }
}

In JVM where spurious wakeups are possible, consider the the case when the thread t is woke up spuriously , the following task assuming that buffer is not empty might break the program.

We have written the code assuming that there are no spurious wakeups allowed.Our code is sure to break in environments where such wakeups are allowed.Our code is not guarded.

So when writing code that waits guard your programs against spurious wakeups,

void method(){
  synchronized(a){
      while(cond / buffer empty){
         a.wait() ;
      }
      //do some task asuming buffer is not empty.
  }
}

In the above code, even when a thread is spuriously woke up, if the condition is  not met we are gonna wait again guarding us against spurious wakeups.

java security - AccessController dopriviledged

I see it as a straight lift of the unix feature setuid.

Source : Wiki

When an executable file has been given the setuid attribute, normal users on the system who have permission to execute this file gain the privileges of the user who owns the file within the created process.

For example the passwd executable.

Inorder for any user to change password one has to get access to the password file and modify its contents corresponding to this user.And its not feasible to give any user write permissions to the password file.

Solution :

A passwd executable owned by root is assigned setuid attribute and this is trusted code.Any non-root user who wants to change is password invokes 'passwd' executable.A process is spawned with its effective userid 'root' as the passwd executable has its setuid set.

Same is the case with AccessController.doPriviledged.

This is my trusted code and have given it permissions to change a file named 'security.txt'

class Trusted{

    public static void  modify(){

         //code to access and modify security.txt file

   }

}

UntrustedCode with no FilePermissions but need to modify security.txt

class UnTrusted {

 public static void modifythroughuntrusted(){

        Trusted.modify();

    }

}

When the above UnTrustedCode is executed there is a security exception raised.Let us examine the call stack,

UnTrusted.modifythroughuntrusted ---> Trusted. modify  ---> FilerelatedOperation which calls securitymanager to look if the current thread of execution has the required permissions to do so.

check 1 )  Trusted. modify ---> has file permission --- true

check 1 )  Trusted. modify ---> has file permission --- false

Hence we receive SecurityException.

Modify the code TrustedClass code 

class Trusted{

    public static void  modify(){

        AccessController.doPriviledged( new PriviledgedAction(){

           public void run(){

                   //code to access and modify security.txt file

          }

       }

   }

}

After this modification  the unTrustedCode will be able to modify the security.txt file, though it does not have the required filepermission.

Let us examine the call stack again

UnTrusted.modifythroughuntrusted ---> Trusted. modify  ---> FilerelatedOperation which calls securitymanager to look if the current thread of execution has the required permissions to do so.

check 1 )  Trusted. modify ---> has file permission --- true & this is marked priviledged so will not check the further callstack for permission and returns, allowing the code to proceed further.

 

---look this section for additions ---