I suspect the article is wrong though. "&T" does not mean "read-only". It means the language won't let you assign to the object's fields directly (because it's not an exclusive reference, so the compiler can't be sure you won't assign in two threads concurrently and cause a data race), but the object may still support interior mutability - e.g. it can contain an AtomicU32 which has functions that can safely mutate it through a &T with no risk of data races.

More usefully it could contain a Mutex (which converts a shared reference "&Mutex<T>" to an exclusive reference "&mut T", but only for one thread at a time). You'd use the semaphore so that only N threads can perform some high-level operation concurrently (maybe you only want 4 HTTP requests at once), while the &T uses fine-grained mutexes around any shared mutable data as normal.

I haven't read the article very carefully but I'm not sure why they don't that. As far as I can see, their design has no explicit link between the semaphore and the thing protected by the semaphore (e.g. the object providing the HTTP request API), even though the thing protected by the semaphore must still be accessed by all the threads through some shared &T (which internally uses atomics/mutexes/etc) because that's the only way to share things between threads in Rust. You could (I think) store that &T inside the semaphore object and return it from the wait() function, and that would make it harder to accidentally write code that forgets to acquire the semaphore before using the associated &T. It wouldn't matter in terms of Rust's safety guarantees, but it seems like that'd be an easier-to-use API.