Should close() release locks atomically?

The close() syscall automatically releases locks.  Should it do so
atomically or is a delay permitted?  I can't find anything in our man
pages or the open group specification that says.

The distinction matters when using O_NONBLOCK.  For example:

fd = open(..., O_DIRECT | O_EXLOCK | O_NONBLOCK); //succeeds
// do some I/O
close(fd);
fd = open(..., O_DIRECT | O_EXLOCK | O_NONBLOCK); //fails with EAGAIN!

I see this error frequently on a heavily loaded system.  It isn't a
typical thread race though; ktrace shows that only one thread tries to
open the file in question.  From the ktrace, I can see that the final
open() comes immediately after the close(), with no intervening
syscalls from that thread.  It seems that close() doesn't release the
lock right away.  I wouldn't notice if I weren't using O_NONBLOCK.

Should this be considered a bug?  If so I could try to come up with a
minimal test case.  But it's somewhat academic, since I plan to
refactor the code in a way that will eliminate the duplicate open().

-Alan