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.