[M3devel] ThreadF.MyID?

[Tony Hosking]

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