Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Jul 1999 22:57:11 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        davids@webmaster.com (David Schwartz)
Cc:        tlambert@primenet.com, unknown@riverstyx.net, chat@FreeBSD.ORG
Subject:   Re: Known MMAP() race conditions ... ?
Message-ID:  <199907162257.PAA16303@usr05.primenet.com>
In-Reply-To: <000001becf24$b6b12eb0$021d85d1@youwant.to> from "David Schwartz" at Jul 15, 99 05:47:00 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > > So, what we get back to is, what's one thing that's wrong with FreeBSD?
> > > Threads.
> >
> > That's actually "what's wrong with applications?".  The closest you
> > can get to blaiming FreeBSD for this is "why can't FreeBSD run
> > these applications that rely on threads in an SMP scalable way?".  I
> > could easily ask a similar question: "why can't FreeBSD run Microsoft
> > Office 2000?".
> 
> 	No, there is a legitimate question here that you are evading. Why does
> FreeBSD block a whole process if one thread blocks? There is no requirement
> that it do so. The standards suggest otherwise. FreeBSD's support of POSIX
> threads is deficient.

FreeBSD's user space threads implementation uses call conversion
to wrap system calls.

As a result, "blocking" system calls do not block other threads.  In
point of fact, a "blocking" call made by a thread will result in a
user space threads scheduler entry, which will result in that thread
being suspended until the blocking call can be completed without
blocking.

This is the definition of a "user space threads call conversion
scheduler", which is a permissable implementation, according to
POSIX 1003.1c.

If you are talking about non-system call interfaces that sit in spin
loops (e.g. library calls), then you are talking about something else
being the source of your problem (i.e. it's not FreeBSD's fault that
the code does not work, it's the code's fault).

Such problem code should be corrected to use a pthread_mutex_t, and
not a spin loop, per the recommendation of POSIX 1003.1c, which is
the standard which defines the pthreads interface.

In other words:

Q:	"Why does FreeBSD block a whole process if one thread blocks?"

A:	"Because the code that is blocking is buggy."

My recommendations would be:

1)	Make sure you are linking against libc_r and not libc

2)	If the problem is in a library, fix the library.  Most
	GNU derived libraries (GDBM, etc.) have the perverse
	assumption about the implemetnation architecture,
	despite the POSIX 1003.1c requirements for writing
	working programs.

3)	If your code, itself, is using spin locks, fix it, becuase
	you should be using pthreads synchrinization primitives if
	you are calling pthreads interfaces (e.g. pthread_create).

4)	If you can identify a bonifide test case in FreeBSD where
	a FreeBSD supplied library or system call causes a block
	rather than a call conversion, please provide a test case,
	and it will be fixed.

I have had no problems running LDAP, ACAP, and other well-written
pthreads using code on FreeBSD, without seeing the problems you
are claiming to see.

Let me know when/if you can provide any test cases, and I will
be happy to help diagnose the actual source of the problem.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




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