The locking requirements for Radiance are really quite minimal:
1) One process says in effect, "I need to have exclusive use of this file"
2) Said process waits until other processes are done reading (or writing) the file.
3) Process gets lock; all other processes unable to read or write the file.
4) Process does its thing, releases lock.
5) Life goes on...
Why is this difficult? Well, it seems that this sort of behavior gets in the way of efficient (i.e., cached) network filesystems, so some versions of NFS don't bother with it, or do it badly. Even implementing our own lock mechanism via creating a separate file that says our ambient file is in use suffers from race conditions. These race conditions have been worked out by the sendmail developers, but the solution is quite complicated. The good news is that it works and has been tested on many different Unix implementations. So, this looks like the easiest path to our goal.
My motivation for doing this work is unfortunately low, because I'm using FreeBSD and OS X systems with perfectly adequate NFS lock managers. I don't even have a good way of testing any proposed fix, because nothing is currently broken for me. That's not to say I don't care if other people are having problems -- it simply means that I'm not in a very good position to help. What we need is a good programmer who uses Radiance on a Linux cluster and can do some testing for us (at least). I also need to free up some time, which has proved challenging, lately. (Hence my short and mistake-ridden replies.)
-Greg