1

Thread 1 (T1) creates the file using

FILE *MyFile = tmpfile();

Thread 2 (T2) then starts writing to the file. While thread 2 is writing, thread 1 occasionally reads from the file.

I set it up such that T2 is temporarily suspended when T1 is reading but, as T1 is only ever reading part of the file T2 won't be writing to (the file is written sequentially), I'm wondering if suspending T2 is necessary. I know this would be OK if FILE was replaced by fixed size array / vector. Just wondering how disc differs from memory.

Edit.

The writes are done using fseek and fwrite. The reads are done using fseek and fread. I assumed that was a given but maybe not from some of the comments. I suppose if T1 fseeks to position X at the same time as T2 fseeks to position Y then who knows where the next read or write will start from. Will take a look at pipes, Thanks for the help.

Improve this question
8
  • Even sharing memory between threads can lead to undefined behavior when your second thread is modifying the memory while thread 1 is watching it. It is possible for thread 1 to see a 'half state' (i.e. read while thread 2 is still busy writing things to memory). You would need something like a mutex to ensure only one thread is accessing it at a time. Commented Jun 5, 2018 at 7:38
  • Thanks for the reply. I've edited my question to read FIXED size array / vector. Re the FILE, is it possible to read and write at the same time? Will the disc OS not receive requests like write, write, write, read, write … and deal with them in the order they arrive? Commented Jun 5, 2018 at 7:54
  • File read/write is related to the disk I/O, as stack/heap to memory. T1 and T2 can mutually exclude each other by using a lock. Commented Jun 5, 2018 at 8:40
  • 1
    Not a good idea. Files are very difficult to use as a form of IPC. If you need a database, use a database. Commented Jun 5, 2018 at 9:39
  • 2
    If you need to pass data, use a tool designed to pass data, such as a pipe. Not one designed to store/save data. Commented Jun 5, 2018 at 10:07

1 Answer 1

Reset to default
3

Mixing reads and writes on a FILE is not even safe when dealing with a single thread. From the manpage of fopen:

Reads and writes may be intermixed on read/write streams in any order. Note that ANSI C requires that a file positioning function intervene between output and input, unless an input operation encounters end-of-file. (If this condition is not met, then a read is allowed to return the result of writes other than the most recent.) Therefore it is good practice (and indeed sometimes necessary under Linux) to put an fseek(3) or fgetpos(3) operation between write and read operations on such a stream. This operation may be an apparent no-op (as in fseek(..., 0L, SEEK_CUR) called for its synchronizing side effect).

So don't assume reads and writes are magically synchronized for you and protect access to the FILE with a mutex.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

But what if he opens the file twice? I can see both the producer and consumer both opening the file with share flags. But I agree with @Andrew Henle who says it's better to use a pipe. OP is using Windows so he can even open the pipe in message mode so he doesn't even have to split the stream of incoming bytes into separate messages...
That is even worse because then you have 2 FILE streams with separate buffers. A write in one FILE wouldn't show up in the other FILE unless it is flushed to disk. And yes, a pipe is better for communicating between threads.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.