[M3devel] ThreadF.MyID?

[Tony Hosking]

MyId is not a standard interface so it can do what it likes.  Also, I  
was trying to match thread Ids to those of the OS (as reported by gdb)  
which recycles them.  No guarantees though.  I don't think they should  
necessarily all be the same from one thread implementation to another.

Antony Hosking | Associate Professor | Computer Science | Purdue  
University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




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

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