[M3devel] ThreadF.MyID?

[Jay K]

Fyi, I made us dependent on pthread_self fitting in an INTEGER, though it can be smaller.

There are assertions that this is ok.

 

I kind of just trolling..looking at pthreads for inspiration how to fix win32 threads..noticing the differences.

We're much better now, but it still definitely hangs sometimes. :(

 

  - Jay
 


CC: m3devel at elegosoft.com
From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Subject: Re: [M3devel] ThreadF.MyID?
Date: Tue, 29 Sep 2009 09:59:15 -0400





On 29 Sep 2009, at 05:24, Jay K wrote:


Probably on Win32 should just use GetCurrentThreadId().
And pthread could just use pthread_self().



Yeah, but the type of pthread_self is indeterminate.


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