[M3devel] ThreadF.MyID?

[Jay K]

Probably on Win32 should just use GetCurrentThreadId().

And pthread could just use pthread_self().

 

 - Jay
 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Tue, 29 Sep 2009 09:18:57 +0000
Subject: [M3devel] ThreadF.MyID?



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/27084154/attachment-0002.html>