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>