Knock on wood

Exclusive Hard 5 ConcurrencyDesign PatternsOperating Systems Nvidia

This problem tests correct multithreaded coordination and clean shutdown behavior for a simple logger.

There are exactly two threads:

  • Producer thread calls log(...) and then stop().
  • Consumer thread calls run().

You do not need to write any input/output parsing.


Constructor

Logger2T(max_buffer_bytes)

  • max_buffer_bytes specifies 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 and run() 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 calls run().

  • 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
Accepted 1/1
Acceptance 100%
Loading editor...
Sample Input:
Running custom tests...
Expected Output: