Network socket concurrency (userland)

[Joerg Sonnenberger]

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