[M3devel] ThreadF.MyID?
Jay K
jay.krell at cornell.edu
Tue Sep 29 11:18:57 CEST 2009
The algorithms for thread id assignment vary on the platforms.
In posix user threads and Win32 threads, it appears to be a number that increments for every new thread.
Not sure what happens after 2 or 4 billion.
On pthreads, it appears to be, well, we maintain an array of threads.
So it is a number between 0 and n where n is the maximum number of threads that have
"ever" been running at the same time. With presumably aggressive reuse of ids.
Ok?
They should all use the same?
It's just that I'm looking at the Win32 code, comparing it to the pthread code:
Win32:
LockMutex(threadMu);
cl := self.closure;
self.id := nextId; INC (nextId);
UnlockMutex(threadMu);
Pthread doesn't have this code.
I don't believe self.closure needs a lock.
And per above, pthreads doesn't need protection here for id, since it is handled elsewhere.
I know this was just discussed in a sense -- MyId is for debugging/diagnostics only and its value can't be depended on for much.
The are obvious advantages/disadvantages to the two schemes.
Win32/Posix recycle "never", so debugging probably easier.
Pthread doesn't waste time/space on the id.
- Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090929/62272a51/attachment-0001.html>
More information about the M3devel
mailing list