Programming

You could just call it once and save the value.

No. That wouldn't work unfortunately. I'd have to save it in something that I would then need to tag along to every function as a parameter. I don't want to do that because I'm building 2 applications in layers, the application in the upper layer shouldn't know about the mechanism of the lower layer, it just calls its header functions.

---------- Post updated 08-06-10 at 02:17 PM ---------- Previous update was 07-06-10 at 10:04 PM ----------

Dunno if this is of interest to anyone but I found a way of retrieving information without resorting to pthread_self as I was describing in this thread...

Code:

pthread_key_t key; /* global key */
key_ret_code = pthread_key_create(&key, NULL); /* initialises the key */

This creates a global key which all threads can access. Then each thread can store a value with that key...(in the form of a void*)

Code:

void* value_data;
ret_code = pthread_setspecific(key, value_data);

Now any thread can call...

Code:

void* value_data = pthread_getspecific(key);

And get access to that data. Just what I was looking for!

Lots more in this useful document...

http://dlc.sun.com/pdf/816-5137/816-5137.pdf

As I suspected it would, pthread_getspecific uses THREAD_SELF anyway -- and that's only in the best case. Worst case it has to plunge in and access other thread memory other ways. Stop trying to be so clever and just use pthread_self, that's what it's there for

Thanks for the heads-up Corona688,

You might be right, but the thing is I had to store the "pthread_t" values in an array anyway, so in my application, after calling pthread_self() I would then always have to search the array for the corresponding "pthread_t" value. (At the moment this search is O(n) but I had planned to get it down to O(log n) using a binary-search algorithm if the number of threads is "high").

The good thing about "pthread_getspecific" is it returns the actual data I wanted, but as you pointed out, it looks a bit "involved" when it's not the best case. Maybe I'll try both approaches and see which is quicker.

Using "pthread_getspecific" might be better in avoiding a cache colision though, rather than threads accessing data in a global table.

Trying to be clever ain't so bad if I can manage to pull it off now and again

Ah. If you're looking up data, then you're probably right. Helps to know your actual question.