多线程一读一写time_t

Question

I'm writing a multithreaded application that have 2 threads. One of the threads receives data from a queue and aggregates it and the other one send the aggregated data to a server.

I want to be able to know the last time that a data was received so I use:

time_t last_data = time(NULL)

to get the correct time on each event (I dont need it to be super accurate but I need it to be fast) and then the other send this value with the aggregated data.

My questions are:

1. Do I have to synchronize this even if this is not very important that I get the most recent update?
2. I tested it with std::atomic<time_t> and it seems to have some performance issues, is there any other faster way?
3. What would be the worst case that can happen if I will not synchronize the read/write?
4. Is there a faster way to get the current time then time(NULL) (don't have to be super accurate)?

---

UPDATE

Here is an explanation of my application workflow.

Application needs: 1. Consume data from external sources using IPC (currently nanomsg ). 2. Aggregate the data to bulks. 3. Send the aggregated data to remote server every given interval (1 second).

Current implementation:

1. Create 2 buffers to hold the aggregated data (one for receiving and one for sending).
2. Create a consumer thread to consume data from IPC and fill the receiving buffer.
3. Create a sending thread that will send the data to the server.
4. Every iteration of the interval the sending thread will swap the buffers (swap pointers and locking using mutex) and send the data to the server.

I don't want that the consumer will wait on network IO so I have created this flow. Can I use event driven here instead of this complex mechanism without all the locking (currently it is working fine but i'm sure it can be better)?

Answer 1

Don't do it that way. You only need one thread. You can use select/poll/epoll. These can wait on your inputs, and at the same time for you output to finish. You will be doing event driven programming, and non-blocking output. It is something worth learning. It is a bit harder at first, but soon makes life easier ie not having the problem that you have now. Also the program will be faster.

Answer 2

Supposing one thread executes:

last_data = time(NULL);

And the other uses last_data but there is no synchronization event between the two then there are no guarantees when or if the revised value of last_data will become visible to the reading thread.

However the most serious possibility is that write of time_t (maybe long ) isn't atomic and another thread could read a corrupt 'part written' value. That could cause glitches in delay and time calculations that might foul downstream process.

You might analyse your program and find that because the two interact there is a sufficient memory fence at some point that guarantees eventual update.

NB: This is an odd situation where I'm suspecting you think something isn't synchronized but it is! The usual experience is the other way around...

Basically there's not really enough information to understand what problem you're having. For example, if the reader thread is the only process to read the time I'd expect to see code like:

Thread 1: If data received, lock L, update time, add to queue, unlock L. Thread 2: If items in queue L, read queue and update time, unlock L .. process item.

In which case the time will be synchronized already.

Please provide a minimum, complete, verifiable example...