The FreeBSD man pages hint at this behavior:
in reply to (tye)Re: flock() broken under FreeBSD?
in thread flock() broken under FreeBSD?
A shared lock may be upgraded to an exclusive lock, and vice versa, simply by specifying the appropriate lock type; this results in the previous lock being released and the new lock applied (possibly after other processes have gained and released the lock).
Requesting a lock on an object that is already locked normally causes the caller to be blocked until the lock may be acquired. If LOCK_NB is included in operation, then this will not happen; instead the call will fail and the error EWOULDBLOCK will be returned.
So, if you try to upgrade your shared lock, you release the lock and get in line behind everyone else blocked for an exclusive lock. If you try to upgrade your exlusive lock to a shared lock, you release the exclusive lock and get in line (behind everyone blocking for an exclusive lock) for a shared lock.