Date: Thu, 10 Dec 1998 17:50:35 -0500 (EST) From: Alfred Perlstein <bright@hotjobs.com> To: Marc Slemko <marcs@znep.com> Cc: "hackers@freebsd.org" <hackers@FreeBSD.ORG> Subject: Re: pread/pwrite Message-ID: <Pine.BSF.4.05.9812101743050.27793-100000@bright.fx.genx.net> In-Reply-To: <Pine.BSF.4.05.9812101428300.463-100000@alive.znep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Dec 1998, Marc Slemko wrote:
> > > (not necessarily addressed specifically at pread/pwrite, but it does
> > > apply to it because of how it is used...)
> > >
> > > Where is the locking if multiple threads are reading and/or writing
> > > from or to the same descriptor at the same time? If you have x
> > > threads reading from a descriptor opened from a file on disk, do
> > > x-1 of them have to wait until the first one finishes before they can
> > > do anything?
> > >
> > > What about with mixed reading/writing?
> >
> > >From looking at the diffs what I think what he implemented was a
> > seek+(write|read) in one syscall.
> >
> > Meaning you do not have to lock an fd when seeking and then writing since
>
> No, I'm talking about how the kernel handles it. It needs to do various
> amounts of locking in various areas. When there are kernel threads that
> people are writing multithreaded programs to use, this matters a lot.
>
> Yes, pwrite and pread are good to have.
I would think it only needs to lock the fd.
without pwrite/pread:
higher level lock -----
| seek() -> locks then unlocks fd
| ....
| read/write() -> locks then unlocks fd
unlock ----
with pwrite/pread:
p(read|write)() -> locks fd
It makes sense, especially since generally the only reason for a seek is
to read or write data.
You can save 2 spinlocks with pread/pwrite, the single lock may be held
longer but not enough to be an issue afaik.
-Alfred
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9812101743050.27793-100000>