CreateThread for Windows 8 Metro

re: CreateThread for Windows 8 Metro

Alecazam — Sat, 15 Jun 2013 23:00:02 GMT

I should clarify that my data was tied to thread id (and that is obtainable in a store app). It's just the thread id of the thread in the thread pool. I could change the legacy code to reference off the thread (event) handle, but I wanted to keep that code unchanged.

re: CreateThread for Windows 8 Metro

Alecazam — Sat, 15 Jun 2013 22:52:06 GMT

I had various routines that would obtain the current thread handle and pull up data off of that. Since your emulation returns the thread back to the pool after the task completes, legacy code does not expect to see the same "thread handle" (emulated or real) appear until CloseHandle is called on the "thread handle". I'm only pointing out that the emulation isn't quite right for legacy code. I know it's an event handle, I use the same approach.

re: CreateThread for Windows 8 Metro

cb — Sun, 10 Feb 2013 01:26:00 GMT

Shawn, good stuff.

I'm curious why you don't just use the Fls functions to replace Tls? (eg. FlsAlloc for TlsAlloc). Should be simpler and possibly faster.

re: CreateThread for Windows 8 Metro

Shawn Hargreaves - MSFT — Mon, 07 Jan 2013 23:36:20 GMT

Alecazam, I don't understand your point here. There is no such thing as a thread handle or thread ID in the Windows Store programming model. All the Win32 APIs that return or accept such values are no longer supported, so these concepts no longer exist.

This emulation code provides an emulation of one method (CreateThread) that does return a 'thread handle', but this is an emulated handle, not a real Win32 thread handle. It works exactly like a real thread handle in that you can block on it using any of the Win32 wait APIs, and it will be signalled as soon as the 'thread' has finished running, and you can CloseHandle on it when you are done using it, but it is not a real thread handle at the Win32 level, any more than this emulated CreateThread method creates a real Win32 thread (actually, the 'thread handle' returned by the CreateThread emulation is a Win32 manual reset event).

This distinction is unimportant, however, because the emulated handle works correctly with the emulated CreateThread, and you do not have access to any of the various Win32 API methods that use real thread handles, so what difference does it make whether the returned value is a 'real' thread handle or not?

re: CreateThread for Windows 8 Metro

Alecazam — Wed, 19 Dec 2012 06:18:40 GMT

The code still needed a wait at the end of the async task to prevent the thread from being returned to the thread pool. Otherwise elements that are tied to the thread handle or thread id get very confused when they see that same thread from the thread pool reused before CloseHandle has been hit. If you try to make your emulation return a threadID, you'll find that the code and suspended thread emulation become a lot more difficult (ie. Microsoft should be adding back this API).

re: CreateThread for Windows 8 Metro

Shawn Hargreaves - MSFT — Mon, 03 Dec 2012 01:52:39 GMT

There isn't directly any such thing as a "thread handle" in WinRT - the actual threadpool task is a WinRT interface, not a Win32 handle at all. The handle returned by my CreateThread emulation is part of the emulation layer, not directly part of the WinRT threadpool implementation. So it's up to my emulation layer to make this work however I see fit (which in the case of this implementation was to copy the behavior of the Win32 CreateThread API).

re: CreateThread for Windows 8 Metro

Alecazam — Mon, 03 Dec 2012 01:47:58 GMT

Thanks Shawn. I didn't realize that you could still wait on a thread handle under WinRT. I've done the DuplicateHandle like you od, but we've been tracking an event with each thread handle. When we get to a Wait, we wait on the event, and not the thread handle. The thought was that the thread handle never signals, because it's just thrown back into the pool.

There's still a need for the physical core count. Logical cores is already obtained from GetNativeSystemInfo. We have SIMD tasks that doesn't benefit from the 2x threads. The unfortunate aspect of a WinRT thread pool is not being able to require a physical core. We need some hinting mechanism to request that.

re: CreateThread for Windows 8 Metro

Shawn Hargreaves - MSFT — Sun, 02 Dec 2012 20:53:01 GMT

Alcazam: my implementation handles the thread exit behavior just fine. The handle returned from the emulated CreateThread remains valid (and can be waited on) until the caller decides to call CloseHandle on it. This isn't tied to when the task completes (they are related because task completion will signal that handle, but it doesn't close it, which is exactly the same as the original Win32 thread behavior).

re: CreateThread for Windows 8 Metro

Alecazam — Sun, 02 Dec 2012 20:13:36 GMT

We're having to implement a thread wrapper for legacy code as well. Not only is it way too complex, but I see that your impl has the same problem as ours.

The thread pool recycles the thread handle as soon as the task completes. That differs from a real thread which stays valid until CloseHandle. We have legacy code that is tracking it's own data off the thread handle. When it see the same thread handle appear, it thinks that thread is being used before it's been released. There needs to be something to prevent the thread/task from going back to the thread pool (yet another event/waitforsingleobjectex at the end of the task).

re: CreateThread for Windows 8 Metro

Shawn Hargreaves - MSFT — Wed, 21 Nov 2012 04:21:55 GMT

ESE:

1) ThreadPool is a Windows kernel component, so yes, all native code. This functionality is exposed as a WinRT interface (ie a vtable containing pointers to code).

2) I don't work on the kernel/threading team who owns that decision, so I can't comment on what they might decide to do in the future. I do know they had good reasons for the decisions made for Win8 Store apps, though.