This routine attempts to acquire a read-write lock for write
    access. If any thread already has acquired the lock for write
    access or read access, the lock is not granted and the calling
    thread blocks until it can acquire the lock. A thread can hold
    only one lock for write access on a read-write lock.

    Results are undefined if the calling thread holds the read-write
    lock (whether for read or write access) at the time this routine
    is called.

    If the read-write lock object referenced by rwlock is not
    initialized, the results of calling this routine are undefined.

    If a thread is interrupted (via a Tru64 UNIX signal or an OpenVMS
    AST) while waiting for a read-write lock for write access, upon
    return from the interrupt routine the thread resumes waiting for
    the lock as if it had not been interrupted.

    Realtime applications can encounter priority inversion when using
    read-write locks. The problem occurs when a high-priority thread
    acquires a read-write lock that is about to be unlocked (that
    is, posted) by a low-priority thread, but the low-priority thread
    is preempted by a medium-priority thread. This scenario leads to
    priority inversion in that a high-priority thread is blocked by
    lower-priority threads for an unlimited period of time. During
    system design, realtime programmers must take into account the
    possibility of priority inversion and can deal with it in a
    number of ways, such as by having critical sections that are
    guarded by read-write locks execute at a high priority, so that
    a thread cannot be preempted while executing in its critical
    section.