Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users

Dashboard
Notifications
Mark all as read
Q&A

Write to same file from multiple threads

+7
−2

I want to write a text file from multiple threads. The file structure is line-oriented. This means writing of lines should be atomic. I am using Qt 5.15.2.

Is it enough to protect a shared QTextStream/QFile pair using a QMutex?

EDIT:

@dmckee‭ Sorry, I tried to post a comment but failed. I could click "post" but the comment didn't appear.

Your solution is how I have solved it currently (well, a bit more complex but it boils down exactly to your idea). However moving the file work into a single writer thread does not scale.

I have a lot of threads writing very big amounts of data. This means the writer thread receives a big load and (more important) queued events need to carry a lot of data (which means a lot of RAM consumption). This gets even more nasty in case the writer thread is too slow: It will pile up events consuming virtually all RAM in the system. This is why I would prefer a mutex like solution very much. Alas, is that possible?

Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

7 comments

Its off-topic in this site ~ i think. I think this question belongs to code golf Istiak‭ 21 days ago

@Istiak, you are either trolling or profoundly confused about what is on topic for software development. Either way, please ease up. r~~‭ 21 days ago

@r~~‭ doesn't Software Codidact is for only solving problems? Code Golf is for completing tasks, isn't it? Istiak‭ 21 days ago

@Istiak Code golf is about solving problems with the least amount of code (bytes). The software development community is (among others) about getting solutions to programming problems. Alexei‭ 21 days ago

Strangely I got notifications for the comments you didn’t manage to actually post. Probably a bug in the engine. dmckee‭ 20 days ago

Show 2 more comments

2 answers

+5
−0

Because you are using Qt in particular there is something to be said for not solving this problem yourself.

Instead, create a single object that owns the stream or file and offers a writeLine slot. In the simplest case the signature might be writeLine(const QString & line). Then your threads simple signal the owner with the data they want to write and the Qt engine takes care of the locking for you.

Why does this post require moderator attention?
You might want to add some details to your flag.

0 comments

+4
−0

Writing to the file on the HD is your massive bottleneck no matter how many threads you throw around. The limit is the physical memory access speed, not processing power. And since it is such a bottleneck, you should have a thread solely focusing on this job, similar to what @dmckee‭ suggested.

Now what you can do is to have the file writer thread work with large chunks of fixed sizes. Don't just write a few lines each time, write a large chunk. You can have other threads preparing the data in advance.

Suppose you have some logging function where you pass on one string at a time, in some icky inconvenient format like std::string or some QT class. Instead of writing 5 strings each one at a time, with a length of some 10 to 100 bytes, show these into a raw byte buffer and let it build up to a certain size. Computers love multiples of 8, so maybe work with chunks of 256 or 512 bytes at a time. And yes we are talking about raw C strings here, forget all about "overloading ofstream", "type generic logging" and other such time-consuming fluff.

As a positive little side-effect, these raw chunks will also be very cache-friendly, unlike a bunch of heap allocated fragments from std::string/std::vector etc. But RAM access speed is a minor concern compared to HD access speed.

This gets even more nasty in case the writer thread is too slow: It will pile up events consuming virtually all RAM in the system.

Yeah that's the thing with queues: if your real-time specification doesn't add up, so that you never end up with an empty queue, then no amount of queueing will save you. The problem could simply be that you are saving too much data too frequently.

Make sure to benchmark on an old SATA/SCSI HD and not on a SSD.

Why does this post require moderator attention?
You might want to add some details to your flag.

4 comments

Also potentially useful: try to reduce unneeded copies. Don’t pass large objects, pass suitable smart pointers to them. dmckee‭ 17 days ago

@dmckee Smart pointers aren't necessarily smart in a multi-threaded context though. Because that makes heap allocated objects behave as if they have local scope. Not what you want - suppose you create a thread from another thread, then the creator finishes and goes out of scope. The smart pointer will then kill all data while you are still using it. You'd have to give it multiple owners, which creates needless bloat and complexity. Lundin‭ 17 days ago

Smart pointers solve the lifetime problem. In cases where the sending code is done with the data you use a std::unique_ptr to transfer ownership. If for some reason the sending code needs to retain access you use a std::shared_ptr which has more overhead but will be at least as efficient as any reference counted system you code up. And while there is some overhead, @Silicomancer says the queued events "carry a lot of data", so saving even one copy might be enough to pay for it. that. dmckee‭ 14 days ago

@dmckee‭ Hmm yeah I just realized I'm not quite up to date with C++. I was thinking auto_ptr but forgot there's a better alternative nowadays. Anyway, plain old manual allocation would do the trick too. Lundin‭ 13 days ago

Sign up to answer this question »