Thread library: get thread id
I'm using boost_1_29_0 and need to get the id of the current thread. Is there a way to get the id of the current thread using boost? I don't see how I can access the current thread (Is there some sort of current function?). If I could access the current thread, I could write a getId() function (in a class subclassed from boost::thread). Only problem there is the return type. It seems the id is an int in windows environment, a pthread_t in POSIX and a MPTaskID in MACOS. Those last two seems to be pointers to struct. I guess it is possible to cast all of them to long (using reinterpret casting), but maybe I am overlooking something then. thanks, Olivier.
olivier_debels said:
I'm using boost_1_29_0 and need to get the id of the current thread.
Why?
Is there a way to get the id of the current thread using boost? I don't see how I can access the current thread (Is there some sort of current function?).
No. This isn't a portable feature. I plan on adding a feature that's similar, and portable, but that's why asked why you need this. I'm not sure the portable interface will suffice for your needs with out knowing what they are.
If I could access the current thread, I could write a getId() function (in a class subclassed from boost::thread). Only problem there is the return type. It seems the id is an int in windows environment, a pthread_t in POSIX and a MPTaskID in MACOS. Those last two seems to be pointers to struct. I guess it is possible to cast all of them to long (using reinterpret casting), but maybe I am overlooking something then.
Casting this way is non-portable. And I don't believe POSIX requires pthread_t to be a pointer, though I haven't researched that in depth yet. William E. Kempf
--- In Boost-Users@yahoogroups.com, "William E. Kempf" <wekempf@c...> wrote:
olivier_debels said:
I'm using boost_1_29_0 and need to get the id of the current
thread.
Why?
Is there a way to get the id of the current thread using boost? I don't see how I can access the current thread (Is there some sort of current function?).
No. This isn't a portable feature. I plan on adding a feature
I have several threads which pop messages from the queue. I want to keep track of what each thread pops (depending on some rules) without adding an extra parameter (threadId) in the pop-function. By this way threads just call the pop-function (they don't know anything about the internal cooking of the queue). They get a message, which fulfills the rules (one of the rules is f.e. that no two threads can handle the same message at the same time). that's
similar, and portable, but that's why asked why you need this. I'm not sure the portable interface will suffice for your needs with out knowing what they are.
If I could access the current thread, I could write a getId() function (in a class subclassed from boost::thread). Only problem there is the return type. It seems the id is an int in windows environment, a pthread_t in POSIX and a MPTaskID in MACOS. Those last two seems to be pointers to struct. I guess it is possible to cast all of them to long (using reinterpret casting), but maybe I am overlooking something then.
Casting this way is non-portable. And I don't believe POSIX requires pthread_t to be a pointer, though I haven't researched that in depth yet.
I guessed this would not be portable...
William E. Kempf
olivier_debels said:
--- In Boost-Users@yahoogroups.com, "William E. Kempf" <wekempf@c...> wrote:
olivier_debels said:
I'm using boost_1_29_0 and need to get the id of the current
thread.
Why?
I have several threads which pop messages from the queue. I want to keep track of what each thread pops (depending on some rules) without adding an extra parameter (threadId) in the pop-function.
I don't follow this.
By this way threads just call the pop-function (they don't know anything about the internal cooking of the queue). They get a message, which fulfills the rules (one of the rules is f.e. that no two threads can handle the same message at the same time).
How does a thread id figure into this? What little of this description I understand gives no need for a thread id. William E. Kempf
--- In Boost-Users@yahoogroups.com, "William E. Kempf" <wekempf@c...> wrote:
olivier_debels said:
--- In Boost-Users@yahoogroups.com, "William E. Kempf"
<wekempf@c...>
wrote:
olivier_debels said:
I'm using boost_1_29_0 and need to get the id of the current
thread.
Why?
I have several threads which pop messages from the queue. I want to keep track of what each thread pops (depending on some rules) without adding an extra parameter (threadId) in the pop-function.
I don't follow this.
By this way threads just call the pop-function (they don't know anything about the internal cooking of the queue). They get a message, which fulfills the rules (one of the rules is f.e.
that no
two threads can handle the same message at the same time).
How does a thread id figure into this? What little of this description I understand gives no need for a thread id.
William E. Kempf
Ok, sorry, I'll try to make it more clear. You have a simple Queue where you can push and pop messages. Popping is done by one or more threads. The threads handle the message before popping the next one. So far so good. This is very straightforward: threads pop a message, handle it, pop a next message and so on... Now, An adjustment must be done: Messages have a certain type and no two threads are allowed to handle a message of the same type at the same time. The push and pop interface must stay the same (no extra parameters are allowed...). This means the pop function must now get the next message and check if no other thread is handling such a message at the moment. In order to do this, I wanted to store the type of message each thread was working on. This means I have a map containing for each thread, the message type he is working on (mapping a threadId onto a message type, here is where the threadId comes in) The pop function would then look something like this (in higher level language): msg* pop() { // Get next message out of the queue // While no message found // Check if no other thread is working on such a messagetype // If not -> return this message // else -> get next message } To check if no other thread is working on such a messagetype, we take a look in the map(threadId, message type). Hope this makes it more clear! Olivier.
olivier_debels wrote:
msg* pop() { // Get next message out of the queue // While no message found ^^^ // Check if no other thread is working on such a messagetype // If not -> return this message // else -> get next message }
To check if no other thread is working on such a messagetype, we take a look in the map(threadId, message type).
But still, what buys you the threadId? if you would change the check to Check if noone is working on such a messagetype and possibly use a set<message_type>, what is missing than? Ali
--- In Boost-Users@yahoogroups.com, Albrecht Fritzsche <albrecht.fritzsche@t...> wrote:
olivier_debels wrote:
msg* pop() { // Get next message out of the queue // While no message found ^^^ // Check if no other thread is working on such a messagetype // If not -> return this message // else -> get next message }
To check if no other thread is working on such a messagetype, we take a look in the map(threadId, message type).
But still, what buys you the threadId? if you would change the check to
Check if noone is working on such a messagetype
and possibly use a set<message_type>, what is missing than?
Ali
I need to know when a message finishes too. So when doing a pop(), I first adjust the map (remove the type this thread was working on). If I just have a set<message_type> and a thread wants to pop another message, I don't know any more which one has finished before. In other words, when do I remove a type out of the set? Maybe I could do this in the destructor of message however, but this seems a bit ugly no?
<albrecht.fritzsche@t...> wrote:
olivier_debels wrote:
msg* pop() { // Get next message out of the queue // While no message found ^^^ // Check if no other thread is working on such a messagetype // If not -> return this message // else -> get next message }
To check if no other thread is working on such a messagetype, we take a look in the map(threadId, message type).
in fact you need one unique thread that read message from queue and dispatch it to the other specialized thread according to the founded type. no problem of critical section (2 thread access the same message in queue)in that design.
participants (2)
-
acarsac <acarsac＠yahoo.fr> -
Albrecht Fritzsche -
olivier_debels <olivier_debels＠yahoo.com> -
William E. Kempf