Seeing as my experience with SQL is completely amateurish (I've only used SQL for things like the CB stats database, never for a commercial-grade system), I want to see if I understand your "pid IS NULL" == "atomic" bit, as that likely would not have occurred to me, largely due to that lack of experience, so this is mostly an effort to internalise it by stating what is likely obvious to more experienced people.
If we simply had UPDATE joblist SET pid = ? WHERE jobid = ?, the theory is that since the determination of the jobid could be happening on two (or more) threads at the same time, and it is NOT part of the same query, the db could return the same jobid to more than one thread, and then they both try to update the db with their pid. In this case, the last one wins, but all earlier updates thought they were successful, so those threads would not know that their jobid was stolen from them.
With the pid IS NULL bit, the first thread to claim the jobid still gets it, but all other threads will have this update statement fail. Thus, it is imperative in this system that one checks the return value from the UPDATE (we'd expect "1" if it succeeded in updating what should be a single row, assuming jobid's are unique, which seems like a reasonable assumption here, and "0" if the row was not updated). If the return shows failure, we need to loop back and find a new satisfactory jobid, and try again.
If I'm understanding this correctly, I may need to go back to my own SQL code to see if this is needed in the CB stats or some such :-) Thanks, tye. And thanks marto for mentioning it in the CB causing me to go looking at it.