Java Concurrency (&c)

Ooookay. You are now, presumably, fresh from reading the original post about using AsyncGetCallTrace and the more recent post about how to use SIGPROF in C++ . The next obvious question is... Can I Register a Signal Handler in Java? Um... Kind of! There is an undocumented and unsupported interface called sun.misc.Signal present in most Java implementations. For those of you who have downloaded the JDK, the files live in /src/share/classes/sun/misc. If you import sun.misc.Signal and sun.misc.SignalHandler , you can define a signal handler like this: // Handles SIGHUP Signal.handle(new Signal("HUP"), new SignalHandler() { // Signal handler method public void handle(Signal signal) { System.out.println("Got signal" + signal); } }); You can raise a signal like this: Signal.raise(new Signal("HUP")); You can even register a native signal handler with the Signal.handle0 method (I'll leave that as an exercise for the reader). Having said that

First, read this post about profiling with JVMTI and SIGPROF . A poster on that entry asked me to elaborate a little on exactly what happens when the timer goes off and the signal is raised. In this post, I'll explain that in a little more detail. First, I'll back up a little. Edited to add: Okay, I wrote this whole thing, and very, very briefly answered the actual question at the end. So, if you are interested in the answer to the actual question, and not a long discourse on how to use SIGPROF, look at the end of this entry . What is a Signal? A signal is a very basic method used either to indicate odd behavior in a program synchronously in UNIX-alike systems. If a process divides by zero, for example, a SIGFPE (Floating Point Exception) is synchronously sent to that process. Signals can also be used asynchronously; for example, one process can send another a signal. The other process determines how it wants to handle that signal when it receives it. That process can ei

This is the answer to the riddle posed in my earlier puzzler posting . You should probably look at that question before looking at this answer. I suppose I should call it something other than a puzzler, to avoid getting hit by Josh and Neal's angry team of vicious, snarling lawyers... This program certainly looks straightforward. It just looks as if two threads are writing to two variables. In fact, you probably expected me to say something "who-cares" oriented about compiler optimizations at this point. Well, they are volatile variables, so you can worry a lot less about potential reorderings. In fact, this one has absolutely nothing to do with program transformations, and, if you ran the program on my laptop, you found that it hangs! It turns out that this is the result of one of those vicious little static initialization quirks that provide so many hours of headaches. What happens is something very like the following. The first thread encounters A ; this class

Although I didn't go this year, one of my favorite parts of JavaOne is always Josh Bloch and Neal Gafter's talk on Java Puzzlers. (This year, Bill Pugh, my graduate advisor, stepped in for Neal.) A puzzler is a short snippet of code which has unexpected results, usually because some language or API feature behaves in a strange way. I enjoy them because I always think it is truly wonderful to have the depth of my ignorance exposed. Josh and Neal wrote an excellent book with all of the Java Puzzlers through 2005 , which is highly recommended, and occupies a place of honor in the stack of books in my bathroom. The point of all of this is that occasionally, I will send Josh a multithreaded puzzler, and he will tell me it is no good, because you can't reproduce it every time. Here's one I sent him a couple of months ago. It turns out that the following snippet of code displays the odd behavior 100% of the time under the JVM on my MacBook Pro (JDK 1.5.0_07), and won't

This is a follow up from my previous post about profiling with SIGPROF and JVMTI . There are, in fact, a very large number of ways of getting stack traces out of a JVM. If you send a system-dependent signal to your JVM process, it will spit out a stack dump of every currently live thread. On Solaris and Linux, the signal is a SIGQUIT, which you can get by using kill -3 on the JVM PID (or the PID of the parent JVM process under Linux 2.4), or hitting Control-\. On Windows, you can achieve the same effect by hitting Ctrl-Break on Windows. If you call Thread.dumpStack() , or create a new Throwable , and invoke getStackTrace() on it, you can get the current stack trace programmatically. If you use ThreadMXBean 's getThreadInfo methods, you can get stack traces out of any threads you want. If you use JVMTI 's GetStackTrace or GetAllStackTraces methods, you can get stack trace information in native code. Most of these methods will tell you if your thread can be scheduled by

There is a very good talk by Lawrence Crowl on the upcoming threading changes to C++ . I wrote a brief entry about his talk on C++0x (where they are hoping for x < 10). They have developed heavily on the work done for the Java model, so that they could resolve some of the C++ absurdities that inevitably occur. Hans Boehm, who was heavily involved in the Java effort, has been leading the effort. One neat feature is the proposed atomic keyword. All accesses to a variable declared atomic will be, obviously enough, atomic. It will support features like compare-and-swap and atomic increment (of numerical types). The neat part is that this will work for more than just scalar types (as it does in most current systems). You can declare an entire object to be atomic, and update it all at once. Efficiency depends, of course, on whether the hardware supports such operations, or they need to be emulated in software. As this is C++, they felt the need to overload operators for atomic