Programming Forums > Application Development > C++

jayme · Apr 9th, 2006, 11:09 PM

I'm not so fond of multithreading because I don't have enough documentation to do what I'm attempting with them.

I have a client that needs to send and receive data simultaneously. Well, more like grab user input and receive data simultaneously. How I have the client at the moment, I have to send a message to the server in order to receive a message because it comes before receiving and the rest of the program goes on hold while the user inputs a message. Is there a way to accuire the same results of multithreading, without having to take care of all the locking/releasing/etc that tags along with threads? A winsock specific solution(like select() for sending and receiving, serverside) would be acceptable as well since I don't really have any other solutions.

If anyone has any detailed tutorials that I could use incase multithreading is the only half decent way for me to go, just let me know. Thanks.

grumpy · Apr 9th, 2006, 11:31 PM

There are alternatives to multi-threading, but they have their tradeoffs as well. And they all involve a radical redesign of either your client or your server (or both). Examples include;

1) Polling in an infinite loop. Essentially you have a loop that continually checks if there is user input and then checks if there is data from your server, and processes anything that comes along (and quits if necessary conditions are met). Essentially;

(Toggle Plain Text)

  while (!told_to_quit)
  {
       if (UserInputAvailable())
          ProcessUserInput();
       if (ServerDataAvailable())
          ProcessServerData();
  }

The problems with this approach are that it doesn't fit in well with GUI event loops (unless you push the polling to another thread), and they tend to flog the machine (eg CPU usage will go to 100% unless you make the system sleep for a few milliseconds each time through the loop) if the checks for data are quick or the GUI will slow down (if the act of checking for server data takes a while).

2) Have your GUI periodically poll for data from the server.

3) Use asynchronous I/O to communicate with your server. The techniques to do this are highly system dependent, and are arguably even more difficult than using threading. There are times when asynchronous I/O are better than using multithreading (particularly when data doesn't come from the server too often), but not always. Essentially, all asynchronous I/O does is make the operating system do the work that you would otherwise hand over to a thread in your own program, and the OS lets your program know when data has been received.

The bottom line is that, if you want to do things concurrently (eg multiple threads in a program, multiple programs that run in parallel and exchange data) that you have your work cut out for you. Multithreading is not the only way, but it is often an easier way.

jayme · Apr 9th, 2006, 11:48 PM

Well I think I'll stick to multithreading in that case. Mutex's seem to be pretty simple after reading about them, I think I might have an understanding of how they work. Does windows come default with a mutex class header? I've tried a few different headers like "afxmt.h" as said by the MSDN library, but apparently I don't have it.

The Dark · Apr 10th, 2006, 12:01 AM

Probably the simplest mutex to use in Windows is the critical section functions.

InitializeCriticalSection;
DeleteCriticalSection;
EnterCriticalSection;
LeaveCriticalSection;

each of these take a pointer to a CRITICAL_SECTION value. Call Initialize once to create the critical section, then call the Enter and Leave functions to lock and unlock it, then call Delete when you are done.

I'd recommend wrapping the calls in a class, and possibly even having a smart "locking" class that you create when you want to lock the mutex (pass the mutex in) that automatically unlocks when the object is destroyed.

There are probably lots of options in other third party libraries as well.

nnxion · Apr 10th, 2006, 4:21 AM

I thought blocking sockets did something like this. I need to look into network programming soon...

grumpy · Apr 10th, 2006, 7:09 AM

Blocking sockets just refers to using functions to read from a socket that don't return until there is some data to return (or if the socket is closed at the other end). i.e. the function is said to block until there is something on the socket to read.

The problem with that in a single thread of execution is that the thread can do nothing else while waiting for data to arrive on the socket, so a function that uses blocking socket calls will often be relegated to a thread of its own. The more usual approach (for polling) is to use a call that returns immediately with a status (eg an indication that data is able to be read by a blocking function optionally with any data that has been read). There are also socket functions (eg select()) which can be used to monitor multiple sockets.

Cache · Apr 11th, 2006, 6:45 PM

Quote:

Originally Posted by jayme

Does windows come default with a mutex class header? I've tried a few different headers like "afxmt.h" as said by the MSDN library, but apparently I don't have it.

If you haven't figured it out yet: the afx prefix usually indicates MFC.

grumpy · Apr 11th, 2006, 7:03 PM

There is not a mutex class header as such under windows. The afx prefix usually indicates MFC, and that drags in the win32 API headers with it.

In the win32 API, the mutex related functions (CreateMutex(), , the various WaitXXX() functions that can be used to grab ownership, ReleaseMutex(), CloseMutex(), etc) are declared in winbase.h.

Apr 9th, 2006, 11:31 PM	#2
grumpy Programming Guru Join Date: Jun 2005 Location: Adelaide, South Australia Posts: 1,260 Rep Power: 5	There are alternatives to multi-threading, but they have their tradeoffs as well. And they all involve a radical redesign of either your client or your server (or both). Examples include; 1) Polling in an infinite loop. Essentially you have a loop that continually checks if there is user input and then checks if there is data from your server, and processes anything that comes along (and quits if necessary conditions are met). Essentially; (Toggle Plain Text) while (!told_to_quit) { if (UserInputAvailable()) ProcessUserInput(); if (ServerDataAvailable()) ProcessServerData(); } while (!told_to_quit) { if (UserInputAvailable()) ProcessUserInput(); if (ServerDataAvailable()) ProcessServerData(); } The problems with this approach are that it doesn't fit in well with GUI event loops (unless you push the polling to another thread), and they tend to flog the machine (eg CPU usage will go to 100% unless you make the system sleep for a few milliseconds each time through the loop) if the checks for data are quick or the GUI will slow down (if the act of checking for server data takes a while). 2) Have your GUI periodically poll for data from the server. 3) Use asynchronous I/O to communicate with your server. The techniques to do this are highly system dependent, and are arguably even more difficult than using threading. There are times when asynchronous I/O are better than using multithreading (particularly when data doesn't come from the server too often), but not always. Essentially, all asynchronous I/O does is make the operating system do the work that you would otherwise hand over to a thread in your own program, and the OS lets your program know when data has been received. The bottom line is that, if you want to do things concurrently (eg multiple threads in a program, multiple programs that run in parallel and exchange data) that you have your work cut out for you. Multithreading is not the only way, but it is often an easier way.

Apr 10th, 2006, 4:21 AM	#5
nnxion Programming Guru Join Date: Jun 2005 Location: elemental plane Posts: 1,429 Rep Power: 5	I thought blocking sockets did something like this. I need to look into network programming soon... __________________ "Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for." -- Socrates

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Apr 10th, 2006, 12:01 AM	#4
The Dark Expert Programmer Join Date: Jun 2005 Posts: 893 Rep Power: 4	Probably the simplest mutex to use in Windows is the critical section functions. InitializeCriticalSection; DeleteCriticalSection; EnterCriticalSection; LeaveCriticalSection; each of these take a pointer to a CRITICAL_SECTION value. Call Initialize once to create the critical section, then call the Enter and Leave functions to lock and unlock it, then call Delete when you are done. I'd recommend wrapping the calls in a class, and possibly even having a smart "locking" class that you create when you want to lock the mutex (pass the mutex in) that automatically unlocks when the object is destroyed. There are probably lots of options in other third party libraries as well.

Apr 10th, 2006, 7:09 AM	#6
grumpy Programming Guru Join Date: Jun 2005 Location: Adelaide, South Australia Posts: 1,260 Rep Power: 5	Blocking sockets just refers to using functions to read from a socket that don't return until there is some data to return (or if the socket is closed at the other end). i.e. the function is said to block until there is something on the socket to read. The problem with that in a single thread of execution is that the thread can do nothing else while waiting for data to arrive on the socket, so a function that uses blocking socket calls will often be relegated to a thread of its own. The more usual approach (for polling) is to use a call that returns immediately with a status (eg an indication that data is able to be read by a blocking function optionally with any data that has been read). There are also socket functions (eg select()) which can be used to monitor multiple sockets.

Apr 11th, 2006, 7:03 PM	#8
grumpy Programming Guru Join Date: Jun 2005 Location: Adelaide, South Australia Posts: 1,260 Rep Power: 5	There is not a mutex class header as such under windows. The afx prefix usually indicates MFC, and that drags in the win32 API headers with it. In the win32 API, the mutex related functions (CreateMutex(), , the various WaitXXX() functions that can be used to grab ownership, ReleaseMutex(), CloseMutex(), etc) are declared in winbase.h.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Programming Forums > Application Development > C++

Multiple tasks - multithreading