lkml.org 
[lkml]   [2002]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Multi-threading
Date
On Monday 11 March 2002 14:54, Andi Kleen wrote:
> Brad Pepers <brad@linuxcanada.com> writes:
> > there is a very complex multi-process dance involving (apparently)
> > multiple debugger interactions per wake up. Kinda like the
> > guys who designed the threads didn't talk to the guys who designed
> > ptrace or one or the other didn't care.
>
> I guess the new futex mechanism that is currently
> designed/debugged/discussed will take care of that. It doesn't require
> signals anymore. Unfortunately it is probably some time off until it can be
> used generally, but at least it is worked on

I'll watch the futex development than and wait for it do be available.

> atomic_dec_and_test() ?

Handles the most common case but not general enough for all cases and its
sister function atomic_inc_and_test is pretty useless.

> atomic_dec_and_return() doesn't strike me as too useful, because
> it would need to lie to you. When you have a reference count
> and you unlink the object first from public view you can trust
> a 0 check (as atomic_dec_and_test does). As long as the object
> is in public view someone else can change the counts and any
> "atomic return" of that would be just lying. You can of course
> always use atomic_read(), but it's not really atomic. I doubt the
> microsoft equivalent is atomic neither, they are probably equivalent
> to atomic_inc(); atomic_read(); or atomic_dec(); atomic_read() and
> some hand weaving.

Apparently the Microsoft one really is in Windows 98 and up (not in 95).
I've had it explained that the asm code (semi-pseudo code here) is like this:

movl reg, #-1
lock xadd reg, counter
decl reg
movl result, reg

This is in comparison to the current code which does something like this:

lock decl counter
sete result

I don't see how the first asm code lies to you. It is returning the value as
it was decremented to and the lock on the xadd keeps it safe.

> BTW regarding atomic.h: while it is nicely usable on i386 in userspace
> it isn't completely portable. Some architectures require helper functions
> that are hard to implement in user space.

Its too bad Linux didn't have a nice wrapper around atom inc/dec/test that
was completely portable. Do you know what arch's have trouble implementing
this?

--
Brad Pepers
brad@linuxcanada.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.113 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site