Semaphores are used to:

A semaphore (Dijkstra, 1965) is an integer synchronization variable manipulated only through two atomic operations — wait (P, decrement) and signal (V, increment). By blocking a process attempting wait when the counter is unavailable, a semaphore caps how many processes may simultaneously enter a shared or critical resource, coordinating concurrent access to that resource.

Applying this here: guarding a critical/shared resource with a semaphore caps how many processes may hold it at once, so competing processes queue for entry rather than racing to read/write the resource simultaneously and corrupting its state.

• Preventing deadlock outright needs a dedicated protocol (for example, imposing a global order on resource acquisition, or eliminating the hold-and-wait / circular-wait conditions) — a semaphore by itself does not guarantee this; in fact, careless use of semaphores (nested waits acquired in inconsistent order) can itself create deadlock.

• I/O operations are carried out by device drivers and the OS I/O subsystem. A semaphore can coordinate which process accesses an I/O device, but it does not perform the I/O itself.

• Memory allocation, deallocation, paging, and segmentation are handled by the memory manager, a separate OS subsystem. A semaphore only guards access to a resource — it does not organize or allocate memory.

So among the choices offered, capping how many processes may concurrently hold a shared/critical resource — so competing processes queue for entry instead of colliding inside it — is what a semaphore mechanically achieves, addressing the contention among processes competing for that resource. Here 'prevent contention' is the exam's shorthand for precisely this — a semaphore serializes/limits concurrent access so competing processes do not conflict (race) inside the resource; it does not eliminate the competition itself, and it does not prevent deadlock (which is why the deadlock choice is not the intended answer).