--- In Boost-Users@yahoogroups.com, "William E. Kempf" 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

--- In Boost-Users@yahoogroups.com, "William E. Kempf" wrote:

olivier_debels said:

...

--- In Boost-Users@yahoogroups.com, "William E. Kempf"

...

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.

--- In Boost-Users@yahoogroups.com, Albrecht Fritzsche 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, 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 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?