The point of this assignment is obviously to demonstrate an understanding of these specific concepts. Not to do production-ready engineering. Hence its contrived requirements.

In real life, you would put the queue on a server designed specifically for them, such as ZeroMQ, RabbitMQ, Kafka or Redis.

Yes, it is clear that this is "an exercise," and I would also consider it to be a well-designed one. I hope that the student in question will embrace it.

I would also encourage the student to work directly and closely with the obviously-skilled instructor who created it and assigned it.

In my experience, the only way to arrange "the reading of a file by multiple processes or threads" is to create a single process or thread which is ultimately responsible for managing the file. Everyone else must issue "requests" to read-or-write specified segments of it, and await the reply. The responsible process now receives these requests one at a time. They are now serialized.

This approach removes all of the uncertainty that is inherent in operating-system level serialization mechanisms, and instead reduces it to a very simple "client/server paradigm." The "server" process or thread now receives all of the requests, one at a time (very fast). It has an extremely simple thing to do, and a clear algorithm for doing it: if there is "contention," this one actor can reliably resolve it. The microseconds required are inconsequential. It is a robust strategy.

Every modern programming language provides the "queue" classes and objects needed to accomplish this – if not a ready-made solution to the entire ("very well-known ...") problem itself. "Do Not Do A Thing Already Done.™"