On Wed, 16 Aug 2000, Peter Jeremy wrote:
> >Here's a simple test-and-set function for the 386 (tested and works):
> Actually, this isn't particularly good coding. It isn't SMP-safe.
you caught me! I'm a lousy assembly programmer!
Actually, that code is so old it predates SMP by a bit ...
Here's the kind of thing I have in mind, wrapped around the pthreads
mutexes. This replaces default pthread mutexes (those with no special
attributes) with possibly fast ones. I haven't done any real timing but
I've verified that a program I have works and runs a lot faster with
these wrappers.
I've looked at the POSIX spec to find the right way to portably
implement low overhead process synchronization.
I think the right way is to add _POSIX_THREAD_PROCESS_SHARED support
so that mutexes can be shared between processes.
There is something vague about the spec. I don't see that you can
On Tue, 15 Aug 2000 10:30:25 -0600 (MDT), Ronald G Minnich <[EMAIL PROTECTED]> wrote:
>The idea is simple: tset is the fastest, but you only want to spin so
>long. Then you want to drop into the kernel, and wait for someone to wake
>you up.
Agreed.
>Here's a simple test-and-set function for the
|> you can have a Linda-like pool of work requests to |hand out to a swarm of
| worker bees.
| ^^^
| Could you please decode this for me? :)
This page talks about Linda, check out the "Linda Basics" section and read about
tuples.
http://www.sca.com/ltutorial.html
Peter Dufault wrote:
> you can have a Linda-like pool of work requests to hand out to a swarm of worker
>bees.
^^^
Could you please decode this for me? :)
Thanks,
Gary
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the bod
> On Tue, 15 Aug 2000, Jonas Bulow wrote:
>
> > After doing some more thinking about the cmpxchgl-lock, it's quite hard
> > to use it together with a technique involving the kernel.
>
> well, no I don't think it is. I used to use it a lot, see my earlier post
> from today.
One point to keep i
On Tue, 15 Aug 2000, Jonas Bulow wrote:
> After doing some more thinking about the cmpxchgl-lock, it's quite hard
> to use it together with a technique involving the kernel.
well, no I don't think it is. I used to use it a lot, see my earlier post
from today.
ron
To Unsubscribe: send mail
John Polstra wrote:
>
> In article <[EMAIL PROTECTED]>, Jonas Bulow
> <[EMAIL PROTECTED]> wrote:
> > John Polstra wrote:
> Actually I thought about this some more, and I'm not all that sure
> it's possible. I haven't actually _tried_ it, but I think you'd end
> up needing a low-level mutex aroun
OK, here's a note from long ago, when this came up before.
Dated: Tue Jul 2 10:48:16 1996
The idea is simple: tset is the fastest, but you only want to spin so
long. Then you want to drop into the kernel, and wait for someone to wake
you up. This thing was quite fast on freebsd, even four year
In article <[EMAIL PROTECTED]>, Jonas Bulow
<[EMAIL PROTECTED]> wrote:
> John Polstra wrote:
>
> > I think the ideal solution would first try to lock the
> > test-and-set lock, maybe spinning on it just a few times. If that
> > failed it would fall back to using a system-call lock such as
> > flo
John Polstra wrote:
> Jonas Bulow wrote
> > Maybe I havn't been thinking enough but wouldn't this lock mechanism
> > be a good choice to use for mmaped:memory accessed by multiple
> > processes?
>
> It depends on the amount of contention you expect. The code in
> lockdflt.c was designed for a ve
12 matches
Mail list logo
