Jump to content

  • Log In with Google      Sign In   
  • Create Account


Multithread Varibles...


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 Lethe   Members   -  Reputation: 100

Like
Likes
Like

Posted 21 July 2001 - 03:58 AM

I''m running a multi-threaded C++ program and simply want to have a global varible which is different for each thread - ie in thread #1 it could contain 6 whilst in thread #2 it could contain 2. Now under borlands compillers (Or windows - it''s specific to one of them at any rate.) it''s quite easy to do -
int __thread GlobalVar;
 
Unfortunatly the program also has to run on linux - so i''m after a way that will work for both or could easilly be integrated with the windows equivalant via the preproccesor. I would prefer to avoid anything thats slow - so having a hash table by the thread number or somthing similer really would be a last ditch techneque. Anyone got any experiance/ideas? Thanks in advance for any help. -Lethe

Sponsor:

#2 Kylotan   Moderators   -  Reputation: 3338

Like
Likes
Like

Posted 21 July 2001 - 04:31 AM

Using C++, aren''t your threads objects of some sort? If so, then these variables should probably be members of your thread objects. As globals should technically be global, and using odd compiler-specific workarounds to make globals less-than-global is generally not a good idea. (Of course, using global variables is usually less than a good idea, but I digress...)

#3 Lethe   Members   -  Reputation: 100

Like
Likes
Like

Posted 21 July 2001 - 04:45 AM

There is no class ''generally'' associated with each thread - there is some data associated with each thread, which is a class, but it can''t be accessed by methods/functions called by that thread - ie they are in different classes that are in use by multiple threads, and passing that data down as a pointer is stupidly impractical.

-Lethe

#4 Pseudo   Members   -  Reputation: 100

Like
Likes
Like

Posted 21 July 2001 - 05:10 AM

There is a simple solution considering you ARE using C++. Encapsulate your threads in a general class, and when you want to create a thread, simply create an instance of that class. The class could have a member variable (the thread specific global variable) as Kylotan suggested, and you''re on your merry way.

#5 Lethe   Members   -  Reputation: 100

Like
Likes
Like

Posted 21 July 2001 - 05:25 AM

That is simply not going to work, as I said before. To put the point across, we''re talking about a 25k line server with different classes for different services within that server - each of these classes is initialised once and used seperatly by different threads - each thead being a different user. These classes methods need access to some thread-specific data which can''t be passed down the line via pointers, cos as I said, it''s 25k lines long and I''m not editting that much code!

-Lethe

#6 Krippy2k   Members   -  Reputation: 134

Like
Likes
Like

Posted 21 July 2001 - 07:10 AM

Depends. You might wanna try and get your hands on an HP C++ compiler for Linux. __thread was original introduced in HP C therefore I''m pretty sure it is in HP C++ as well

Otherwise, if I am not mistaken, underneath __thread uses a hash table of dynamic structures for each thread, and this is also the method used on alot of procedural Unix servers which do not use HP C.

It is only slow if you expect tens of thounsands of simultaneous connections.

Seeya
Krippy

#7 Lethe   Members   -  Reputation: 100

Like
Likes
Like

Posted 21 July 2001 - 08:01 AM

Intresting - I''ll look into that, though I would of guessed that it wasn''t a hash table but stored in each thread''s data block - if it turns out to be a hash table I might as well just code it myself though.
Thanks.

-Lethe

#8 WarMage   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 July 2001 - 02:13 PM

So your thread instances sound like "singleton" (I hate that word, BTW) classes for each service you are running? If this is TCP/IP (or any other handshaking protocol) then you''re going to need a listener thread class and a separate worker thread class, wouldn''t you? This would allow your service listener to be singleton, and manage (fork and kill) each of the other separate processes that are its working connections. This is how we solved a multithreading problem in *nix without having to debug something like pthreads and make it work on more esoteric environments.

the listener receives your request, then takes the socket handle (pid, whatever) and hands it as a paramater to a forked open worker thread. Data is matched up by having a place in the message (or in your internal messaging layer) that holds the pid of the worker process in question. the message is passed from worker to the engine class doing all the db work or whatever, and the engine class knows to which pid it should hand the completed work.

Sounds like fun, huh. Secondarily, if you need globals that work across the board, you may as well keep a memory map or memory-mapped-file that is managed by a Globals class, also singleton, to which you would talk in order to retrieve your global values.

------------
-WarMage
...sorry for the mess, you''ll clean it right up.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS