Knock on wood
This problem tests correct multithreaded coordination and clean shutdown behavior for a simple logger.
There are exactly two threads:
- Producer thread calls
log(...)and thenstop(). - Consumer thread calls
run().
You do not need to write any input/output parsing.
Constructor
Logger2T(max_buffer_bytes)
max_buffer_bytesspecifies the maximum number of bytes your logger may buffer internally at a time.If buffering a new message would cause the buffered total to exceed
max_buffer_bytes,log(...)must block (or spin/yield) until there is enough space.
Methods
log(msg, len)
Appends a log record.
Must be called only by the producer thread.
Must not drop messages.
Must preserve FIFO order.
Must not call
judge::write(...).
stop()
Signals that no further
log(...)calls will occur.Must be called exactly once by the producer thread.
After
stop()is called, the consumer must eventually flush all remaining messages andrun()must return.
run()
Runs the consumer loop.
Must be called only by the consumer thread.
Must forward messages by calling
judge::write(...).Must block (or wait) efficiently when there is no work.
Must return only after:
stop()has been called, and- all queued messages have been written.
Judge-Provided API
This function is implemented by the judge and may be called by your code.
judge::write(bytes, len)
bytes- Pointer to the message bytes to write.
len- Number of bytes to write.
Each call writes exactly one log record to the sink.
The sink is thread-safe, but your solution must call
judge::write(...)only from the consumer thread.
Notes
Exactly one producer thread calls
log(...)/stop(), and exactly one consumer thread callsrun().You may use any thread-safe technique (mutexes, condition variables, atomics, spin-waiting, etc.).
The grader checks for:
- missing messages
- duplicate messages
- incorrect ordering
- failure to flush all messages before
run()returns - deadlocks
Running custom tests...