Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Nov 2010 17:33:54 +0100
From:      Joerg Sonnenberger <joerg@britannica.bec.de>
To:        freebsd-hackers@freebsd.org
Subject:   Re: Network socket concurrency (userland)
Message-ID:  <20101116163354.GA4720@britannica.bec.de>
In-Reply-To: <ibu994$les$1@dough.gmane.org>
References:  <ibu503$up9$1@dough.gmane.org> <20101116151903.GA2361@britannica.bec.de> <ibu994$les$1@dough.gmane.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 16, 2010 at 04:51:04PM +0100, Ivan Voras wrote:
> On 11/16/10 16:19, Joerg Sonnenberger wrote:
> >On Tue, Nov 16, 2010 at 03:37:59PM +0100, Ivan Voras wrote:
> >>Are there any standard-defined guarantees for TCP network sockets
> >>used by multiple threads to do IO on them?
> >
> >System calls are atomic relative to each other. They may be partially
> >executed from the perspective of a remote system, e.g. due to
> >segmentation, but one system call will finish before the next call of
> >the same category is started.
> 
> It seems to me that with a multithreaded kernel and multithreaded
> userland that cannot really be guaranteed in general (and really
> should not be guaranteed for performance reasons), but maybe it's
> true for e.g. sockets if they are protected by a mutex or two within
> the kernel?

Of course it can be guaranteed. There are a few tricky bits like writing
to a file with O_APPEND, but for sockets it is essentially all about
taking a mutex before changes the socket buffer.

> >>Specifically, will multiple write() or send() calls on the same
> >>socket execute serially (i.e. not interfere with each other) and
> >>blocking (until completion) even for large buffer sizes? What about
> >>read() / recv()?
> >
> >All write operations are serialised against each other, just like all
> >read operations are serialised against.
> 
> To what degree is such serialization standardized (by POSIX?)?

It is written somewhere, I forget where and can't find it right now :)

Joerg



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