Looking for design advise - Statistics reporter

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 responsib开发者_开发知识库le 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?

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 ;)

The main problem is how to update the info - should i use one mutex for the object or use mutex per basic element?

Put a mutex around the basic unit of update action. If this is an InfoReporterElement object, you'd need a mutex per such object. Otherwise, if a row is updated at a time, by any one of the threads then put the mutex around the row and so on.

Also, which object should be a threads - the reporter itself, or the one that received updates from the threads?

You can put all of them in separate threads -- multiple writer threads that update the information and one reader thread that reads the value.

You seem to have a pretty good grasp of the basics of concurrency.

My intial thought would be a queue which has a mutex which locks for writes and deletes. If you have the time then I would look at lock-free access.

For you second concern I would have just one reader thread.

A piece of code would be nice to operate on.

Attach a mutex to every InfoReporterElement. As you've written in a comment, not only you need getting and setting element value, but also increment it or probably do another stuff, so what I'd do is make a mutexed member function for every interlocked operation I'd need.