[go-nuts] Please help with Locking without Blocking problem???

I need help implementing this in pure Go (without needing external library.
Standard lib is OK):

I have an array of n pointers, each point to a struct that store some
incremental counters. No two pointers in the array point to the same struct
in memory so it's a straightforward 1-1 relationship.

Each struct is updated by an independent goroutine. Therefore we have n
goroutines, called workers. But they share nothing because each only
operate on their own struct, so no synchronization needed between them.

A scheduler run on another independent goroutine periodically needs to sort
the array based on the counters in the structs. Using the sorted array, the
scheduler will do some processing of its own (I can't mention the details
here). No matter what scheduler's processing is, it will only read from the
structs.

To be clear: workers write to the structs and scheduler read from those.

When the array is being sorted (or used) by scheduler, no update (write)
from workers is allowed to occur to the structs. But the workers must keep
running (processing things, doing IOs, ...), without updating the counters
in the structs. The purpose of it is for scheduler to have a consistent
view/snapshot of the structs at processing time. Of course, those counters
could temporarily be store locally to the stack at that time and later when
the scheduler is done, it will be synced back to the structs again by the
workers.

What I want is some kind of lock that:
+ There is only a single lock instance that is referenced by all workers
and the scheduler.
+ Has the same characteristics/properties as readers-writer lock but in
reverse for this case: the readers is the workers that write, the writer is
the scheduler that read. To be specific:
_ Any number of readers (workers) could hold the lock at the same time but
if and only if the writer (scheduler) isn't currently holding the lock. And
the writer could hold the lock if and only if no readers is currently
holding the lock.
_ When writer want to acquire the lock, all future wanna-be-readers must
fail to acquire the lock until the writer release it. But still writer must
wait for all current already-be-readers to release the lock to be able to
hold it.
+ Only writer could be blocked waiting for all current readers to release
the lock. Any worker who wants to be reader may try to acquire the lock but
it must not be blocked when failed (because the lock is currently held by
the writer).

I am still an amateur in concurrent programming so please be specific and
give as much information as you care in your answers. I'd appreciate any
information or advices you could give me. Thanks very much.