I think I've got my own answer here. I think the System calls are
causing timing differences later in the program because
of context switching in the OS. The process is probably getting
switched out and changing the time slice remaining for
the process enough that subsequent switches occur at different
locations during code execution. If I remember correctly,
the time slice on Solaris (on which I'm running this) is 100ms.
If anyone else has any ideas, please feel free to add them...
Thanks.
On Jan 24, 3:06 pm, bobroberts_...@yahoo.com wrote:
> I've taken a "deadlock" sample from a java Sun tutorial page and
> modified it slightly. It's exhibiting some behavior that I find
[quoted text clipped - 62 lines]
>
> -Bob
Tom Hawtin - 25 Jan 2007 00:07 GMT
> I think I've got my own answer here. I think the System calls are
> causing timing differences later in the program because
[quoted text clipped - 3 lines]
> locations during code execution. If I remember correctly,
> the time slice on Solaris (on which I'm running this) is 100ms.
It's quite possibly the loading of code in java.io (and potentially
other compiling) taking time. If you do it at the start of main, it has
all happened before you start your threads. If you don't your first
thread grabs a lock, and then spends time dawdling, in which time the
other thread can grab the other lock first.
The strange effects with having compilers threads and on stack
replacement. You should also note that multicore (or multiprocessor)
machines may behave (i.e. deadlock) differently. Software developed on a
multicore machine may start deadlocking on single core machine, and vice
versa.
So, "it looks alright to me" and "it works on my PC" are not good enough
excuses...
Tom Hawtin