Is there a rule governing generation of RTX task ids OS_TID? It would be interesting to know:
a. if they are incremented sequentially, and b. if there is a max value for OS_TID
I am writing a lib which will cache some data in a buffer. That lib can be called from multiple tasks at the same time, so I want to keep separate buffers for each task. If OS_TID is deterministic then it will be a good differentiator for the per-task buffers.
Any other suggestions are welcome too.
Thanks
"Just an addendum. The code to find a free thread ID is almost certainly deterministic."
Yes. But it's not promised to remain same so users can't rely on it. Unix promise to keep way pids are generated same so they can be relied on.
You can assign, store and compare thread ID:s if using the specified data type. So any code that stores the returned value in a variable of that type will be fine.
Maybe you could explain exactly what additional promise you think you get from Windows or Linux or BSD or OS X? They don't promise that you can predict what the next value will be. And they do not promise if they will use a subset or the full range the data type can store.
This seems to be what Windows promises: "Numeric identifier used to distinguish one process from another. ProcessIDs are valid from process creation time to process termination. Upon termination, that same numeric identifier can be applied to a new process. This means that you cannot use ProcessID alone to monitor a particular process. For example, an application could have a ProcessID of 7, and then fail. When a new process is started, the new process could be assigned ProcessID 7."
On Win32, the process ID is a uint32.
I haven't checked if it has changed on Win64, but the Win64 systems I have observed seems to limit itself to 16-bit values. But I have no way to prove if this is true, without trying to create 64k+ processes - and MS doesn't seem to give any such promise.