Re: pwrite() and threads

[Wouter Klouwen <dublet%acm.org@localhost>]

Sad Clouds(cryintothebluesky%googlemail.com@localhost) said 2010.05.26 15:13:08 
+0000:
> On Wed, 26 May 2010 13:50:05 +0000
> Wouter Klouwen <dublet%acm.org@localhost> wrote:
> > There is another option. Have one thread dedicated to writing, have
> > all other threads pass a message to this thread with the data they
> > wish to have written to what location. This single thread can then
> > proceed to append to each file in order without locking issues. As an
> > improvement to parallelism there could be a small pool of these
> > threads each dedicated to certain files. 
> > Avoiding threading safety issues is better than dealing with them.
> 
> You would still use locking, only this time you would also need
> condition variables to signal to other threads when the copy was
> complete.

Of course. It's a threading problem, so therefore locking is involved. The
issue here is where do you want the locking to happen? 
Using a semaphore (or condition variable) isn't terribly complex and may
actually aid code clarity. Being able to maintain your threaded code is an
important issue. 
Does your library care when the writing of data is complete, or does it only
care whether or not an error occured?

> I think it's simpler to lock a mutex, write to file descriptor and
> unlock a mutex when copy is done. If you buffer your data, then
> overhead of locking should be negligible.

Depends how you want the rest of the system behave when it's locking your
entire thread because it's writing. I/O can be very slow and if the OS is
already writing a bunch of data, you may get some serious delays.

Anyway, it's just a tought and it seems to me that this is hardly a NetBSD
specific problem.

        Wouter