fsync() and write() in different threads

Question

I am trying to write program using fsync() and write() but fsync need time to sync data but i haven't this time to wait. I made one more thread for fsync() Here is my code:

#include <thread>
void thread_func(int fd) {
    while (1) {
       if(fsync(fd) != 0)
           std::cout << "ERROR fsync()\n";
       usleep(100);
    }
}
int main () {
    int fd = open ("device", O_RDWR | O_NONBLOCK);
    if (fd < 0) {
        std::cout << "ERROR: open()\n";
        return -1;
    }
    std::thread *thr = new std::thread (thread_func, fd);
    if (thr == nullptr) {
       std::cout << "Cannot create thread\n";
       close (fd);
       return -1;
    }
    while (1) {
       if (write (fd, 'x', 1) < 1)
          std::cout << "ERROR write()\n";
    }
    close(fd);
}

Question is:

is it need to lock different thread when i use file descriptor to fsync in other thread than main? when i test my program without mutex it have no problem. and when i read man description for fsync it have nothing for different thread.

Answer 1

If the fact that fsync takes time and even sometimes blocks for a very short time is a problem, then you are most probably doing something wrong.

Normally, you do not want to call fsync at all, ever. It is a serious anti-optimization to do so, and one will only ever want to do it if it must be assured that data has been written out¹. In this case, however, you absolutely want fsync to block, this is not only works-as-intended, but necessary.
Only when fsync has returned, you know that it has done its task. You know that the OS has done its best to assure that data has been written, and only then it is safe to proceed. If you offload this to a background thread, you can just as well not call fsync, because you don't know when it's safe to assume data has been written.

If initiating writes is your primary goal, you use sync_file_range under Linux (which runs asynchronously) followed by a call to fsync some time later. The reason for following up with fsync is both to ensure that writes are done, and the fact that sync_file_range does not update metadata, so unless you are strictly overwriting already allocated data within the file, your writes may not be visible in case of a crash even though data is on disk (I can't imagine how that might happen since allocating more sectors to a file necessarily means metadata must be modified, but the manpage explicitly warns that this can happen).

---

¹The fsync function still does not (and cannot) guarantee that data is on a permanent storage, it might still be somewhere in the cache hierarchy, such as a controller's or disk's write cache.