CODEWITHSUNDEEP
c++clinuxio
shoc
shoc

Reputation: 143

fsync() and write() in different threads

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.

Upvotes: 4

Views: 2469

Answers (2)

Damon
Damon

Reputation: 70136

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 out1. 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).

1The 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.

Upvotes: 5

Sergey L.
Sergey L.

Reputation: 22542

Unless you require the thread for something else I would suggest you use the asynchronous I/O aio library:

struct aiocb fsync_cb = {
      .aio_fildes = fd
    , .aio_sigevent = {
        .sigev_notify = SIGEV_NONE
    }
}

aio_fsync(O_SYNC, &fsync_cb);

There is also an equivalent variant for write.

struct aiocb write_cb = {
      .aio_fildes = fd
    , .aio_buf = buffer
    , .aio_nbytes = nbytes
    , .aio_offset = offset
    , .aio_sigevent = {
        .sigev_notify = SIGEV_NONE
    }
}

aio_write(&write_cb);

If you choose not to have any notificaton of success then you will have to check/wait at some point for completion:

while (aio_error(&write_cb) == EINPROGRESS);

Upvotes: 2

Related Questions