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

[David Xu]

Jeff Roberson wrote:

> Does the tid allocator quickly recycle numbers?

Yes, I saw this behavior.


>  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.

> 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 ?

> 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.