-1

This is related to How to assign unique ids to threads in a pthread wrapper? and The need for id_callback when in a multithread environment?.

When we need to differentiate among unique threads, we cannot use functions like pthread_self because thread ids are reused. In those problems, it was suggested to use a monotonically increasing counter to provide a unique id due to counter potential thread id reuse. The counter is then passed to the thread by way of arg in pthread_create.

I don't think we can maintain a map of external thread ids to unique ids because of the reuse problem. The same thread id could have multiple unique ids.

How do we retrieve the arg passed to pthread_create from outside the thread? Is it even retrievable?

Community
  • 1
  • 1
jww
  • 97,681
  • 90
  • 411
  • 885

1 Answers1

1

I don't think we can maintain a map of external thread ids to unique ids because of the reuse problem. The same thread id could have multiple unique ids.

You can, as long as in this map you only keep the external thread IDs corresponding to currently running threads. When a thread exits, you remove it from the map.

The user of the map obviously only cares about currently running threads, since apparently the only way it has to identify the thread it wants is the external thread ID.

caf
  • 233,326
  • 40
  • 323
  • 462
  • Thanks caf. Is there any way to ask for the `arg` back? That is, given a thread id that could have been reused, how do we get it to tell us its `arg`? – jww May 11 '15 at 04:40
  • No, the only way is to stash that association in a data structure somewhere. – caf May 11 '15 at 05:34