Multithreaded File Copier & Custom Memory Allocator

The single-file copier is a real producer–consumer: a team of reader threads pulls lines from the input, a team of writer threads drains them to the output, and a shared queue capped at 20 lines sits between them.

Three mutexes with distinct jobs — one guarding the queue, one serialising reads of the input file, one serialising writes to the output — rather than one lock over everything, so readers and writers only contend where they genuinely share state.

No busy-waiting anywhere. Two condition variables carry the handoff: readers wait on `not_full` when the queue is at capacity, writers wait on `not_empty` when it is drained, and main broadcasts on `not_empty` once reading is finished so no writer can block forever on a queue that will never fill again.

Termination is the part that is easy to get subtly wrong: a writer exits only when the queue is empty *and* the reading-done flag is set, checked while holding the lock, so a writer can never mistake a momentary lull for the end of input. Verified under valgrind with no leaks and no errors.

The allocator asks the kernel for memory itself via `sbrk` and keeps two intrusive linked lists — allocated and free — instead of leaning on the C library it is replacing. Requests are rounded up to size classes of 32, 64, 128, 256 and 512 bytes.

First-fit and best-fit sit behind one function pointer, and `main` picks between them by inspecting `argv[0]` — so a single source file compiles to two binaries, `firstfit` and `bestfit`, that differ only in the strategy and can be run head-to-head on the same trace file.

What it deliberately does not do is coalesce: a freed chunk goes back on the tail of the free list at its original size class, so adjacent free blocks are never merged. That is the honest limitation of the design, and the reason the two strategies diverge on a long allocation trace at all.