Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 Sep 1998 20:09:26 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        mal@algonet.se (Mats Lofkvist)
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: pthreads and sync writes
Message-ID:  <199809202009.NAA28679@usr04.primenet.com>
In-Reply-To: <199809201010.MAA21297@kairos> from "Mats Lofkvist" at Sep 20, 98 12:10:09 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> Is it possible to do a sync write from a thread without blocking
> the process completely? I have tried with open(O_FSYNC) and by
> calling fsync() after writev(), but neither seem to make any other
> thread runnable.

The point of the system call is to block the caller until the caller
is guaranteed that the cached contents of the file are the same as
those on on disk (i.e., it flushes the write-through cache).

This is a place where an async call gate would be useful.


> Btw, O_FSYNC isn't documented in open.2.

Then the man page is broken, since this has existed as an option to
open(2) in UNIX for a very, very long time.


> Fsync()ing also seems to be sligtly faster, is this an illusion or
> is there a difference in the semantics?

When you write to a file with O_FSYNC, the write does not return
until the data has been committed.

When you write to a file without O_FSYNC and subsequently call
fsync(2) on the descriptors, all dirty buffers are written to
disk.

As a result, the second case will give better performance if your
application is such that you can do multiple writes before calling
fsync(2) without sacrificing data integrity in the process.  What
happens is, effectively, write-gathering.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809202009.NAA28679>