Question

I need to implement a statistics reporter – an object that prints to screen bunch of statistic.
This info is updated by 20 threads.

The reporter must be a thread itself that wakes up every 1 sec, read the info and prints it to screen.

My design so far: InfoReporterElement – one element of info. has two function, PrintInfo and UpdateData.
InfoReporterRow – one row on screen. A row holds vector of ReporterInfoElement.
InfoReporterModule – a module composed of a header and vector of rows.
InfoRporter – the reporter composed of a vector of modules and a header. The reporter exports the function ‘PrintData’ that goes over all modules\rows\basic elements and prints the data to screen.

I think that I should an Object responsible to receive updates from the threads and update the basic info elements.

The main problem is how to update the info – should I use one mutex for the object or use mutex per basic element?
Also, which object should be a threads – the reporter itself, or the one that received updates from the threads?

Answer 1

I would say that first of all, the Reporter itself should be a thread. It’s basic in term of decoupling to isolate the drawing part from the active code (MVC).

The structure itself is of little use here. When you reason in term of Multithread it’s not so much the structure as the flow of information that you should check.

Here you have 20 active threads that will update the information, and 1 passive thread that will display it.

The problem here is that you encounter the risk of introducing some delay in the work to be done because the active thread cannot acquire the lock (used for display). Reporting (or logging) should never block (or as little as possible).

I propose to introduce an intermediate structure (and thread), to separate the GUI and the work: a queuing thread.

• active threads post event to the queue
• the queuing thread update the structure above
• the displaying thread shows the current state

You can avoid some synchronization issues by using the same idea that is used for Graphics. Use 2 buffers: the current one (that is displayed by the displaying thread) and the next one (updated by the queuing thread). When the queuing thread has processed a batch of events (up to you to decide what a batch is), it asks to swap the 2 buffers, so that next time the displaying thread will display fresh info.

Note: On a more personal note, I don’t like your structure. The working thread has to know exactly where on the screen the element it should update is displayed, this is a clear breach of encapsulation.

Once again, look up MVC.

And since I am neck deep in patterns: look up Observer too 😉