Messages in this thread | | | From | Brad Pepers <> | Subject | Re: Multi-threading | Date | Mon, 11 Mar 2002 17:02:50 -0700 |
| |
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/
| |