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
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on Write to same file from multiple threads

Parent

Write to same file from multiple threads

+8
−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:

For now using dmckee's‭ solution I have solved it (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?

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

General comments (7 comments)
Post
+6
−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.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

General comments (5 comments)
General comments
dmckee‭ wrote over 3 years ago

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

Lundin‭ wrote over 3 years ago · edited over 3 years 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.

dmckee‭ wrote over 3 years 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.

Lundin‭ wrote over 3 years 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.

Ayxan Haqverdili‭ wrote over 3 years ago · edited over 3 years ago

@Lundin std::auto_ptr is actually removed from the language in C++17. And ref counter of std::shared_ptr is atomic. The thing some people get wrong is that the object pointed by std::shared_ptr is not synchronized. Just the ref counter. Something to be aware of.