cvs commit: src/sys/conf files src/sys/kern init_main.c kern_cpuset.c kern_thread.c syscalls.master src/sys/sys _types.h cpuset.h proc.h types.h src/lib/libc/sys Symbol.map

[Jeff Roberson]

On Tue, 4 Mar 2008, David Xu wrote:

> Jeff Roberson wrote:
>
>> Does the tid allocator quickly recycle numbers?
>
> Yes, I saw this behavior.

I see, it uses unr.  We should introduce some flags to this to prevent 
quick recycling anyway.

>
>
>>  This would be different from the pid allocator if it does.  Basically 
>> every syscall that takes a numeric id would be subject to this problem.
>> 
>> I expect application programers will more often specify binding from within 
>> the running thread using -1.
>> 
>
> Don't know, but I feel it is more often the calling will be made
> for threads within same process, so searching it globally is not
> efficient in this case, and garbage id may hit an irrelevant thread in
> another process.

This is an application race.  I think if we slow down the id recycling 
we should not bother with it.

>
>> However, there is a seperate problem that is endemic with our current 
>> threading support.  thread_find() requires the proc lock and returns a 
>> pointer to the found thread.  However, the proc lock is not sufficient to 
>> ensure that the thread is not exiting and recycled after thread_find() 
>> returns.  I believe virtually every user of this interface may be subject 
>> to races.
>> 
>
> threads are linked into or removed from process with proc lock held,
> why will a linked-in thread be recycled ?

You are right.  I thought it was only the PROC_SLOCK.  But as long as the 
PROC_LOCK is held that's ok.

>
>> And while were on the subject.  Why is it lwpid_t anyway?  We don't have 
>> lwps, we have threads.
>> 
> lwpid_t is used for thread id, I thought marcel introduced this type, by the 
> way, gdb also understands lwpid_t, I have not found any problem with
> it, it is just an integer.
>
>
>