I can tell you one thing that I see which is not as intended, and another kind of broader suggestion.
Note the new setting of thread status? Well, by default when you declare a boolean field (class data member) in java, it will be set false. So when your code enters that loop and tests for the first time whether the value matches, it never will for the second thread. I added the commented line to cause the turn status to be different for the second thread (which is set to the opposite boolean value). This causes both threads to actually go forward. And it is because there is no way for that boolean variable to transition (see line 29 in your code) that the second loop goes into an endless loop and never exits.
Now the other observation. This code looks like it is trying to solve one problem two different ways. On the one hand you have two different threads, and on the other you have this if-check within the while block to switch one thread on or off. Even after I made this change I don't see the desired behavior. There are outputs from each thread interspersed but they are not in the order you wanted. Another symptom of this split is that your synchronization variable is separate for each thread. If you make a "new Turn()" outside of the MyThread class you might also get better results.
I see this as a nice exercise; I would not be trying to force two threads to synchronize in this fashion. If I were, I might instead establish some kind of "round robin scheduling" approach. For that, there would be a shared monitor object (like Turn) that would just have each thread waiting for it with a "notify" like you have there. You could also lookup "Round Robin" and see if it leads you back to the Java concurrency package. I've never bothered to look.
Give that a try.
If a chicken that is half full crosses the road, will anyone hear it?