C / C++ / MFC

12-Aug-08 4:20

Hello, I'm pretty new to programming. I have 2 programs: a server and a client. i want the server to accept messages and do any message processing on a different thread while i keep it's main thread available to whatever i want (this is only something i'm doing to get accustomed with threads & sockets). So, i have an AbstractStream class which is inherited by an ServerStreamSocket class and a AbstractServerCommsThread class which is base class for ServerSocketCommsThread. In the main of the program i create a ServerStreamSocket * ss and after initalising the socket i pass it the thread to be used: ServerSocketCommsThread *thr = new ServerSocketCommsThread(ss). The thread should be started by thr->Run(). Run()creates a thread using a friend function ThreadMe to which it passes a pointer to the object so the threading class has acces to the ServerStreamSocket. Now, i tried doing something really stupid in the threaded function, like outputting a character for 400 time and outputting a different character in the main function to see if they are sequential or not, and unfortunately they are sequential. Any idea why this is?

Here the threading class implementation and the main function:

int main()
{
ServerStreamSocket *ss = new ServerStreamSocket();
ss->init(11000);

ServerSocketCommsThread *sockThr = new ServerSocketCommsThread(ss);
sockThr->Run();
for (int i = 0; i < 400; i++)
cout << "o ";

return 0;
}

class ServerSocketCommsThread : public AbstractServerCommsThread
{
private:
AbstractStream *stream;
pthread_t tid;

public:
void Run();
public:
ServerSocketCommsThread( AbstractStream *pAS);
~ServerSocketCommsThread();

//threaded function must be static or global
friend void* ThreadMe(void *arg);
};

ServerSocketCommsThread::ServerSocketCommsThread( AbstractStream *pAS)
{
this->stream = pAS;
}

void ServerSocketCommsThread::Run()
{
pthread_create(&tid, NULL, ThreadMe, (void*)this);
//return;
}

void* ThreadMe( void *arg)
{
ServerSocketCommsThread *hdl = (ServerSocketCommsThread*)arg;
char in[300];
hdl->stream->write("Starting thread", 300);
cout << "thread started!";

/*char recBuff[300];

while(1){
hdl->stream->read(recBuff, 300);
cout << recBuff << endl;
}*/
for (int i = 0; i < 400; i++)
cout << "x ";
}

Roger Stoltz12-Aug-08 5:20

12-Aug-08 5:20

tiberiuv wrote:
Now, i tried doing something really stupid in the threaded function, like outputting a character for 400 time and outputting a different character in the main function to see if they are sequential or not, and unfortunately they are sequential. Any idea why this is?

If I understand you correctly you believe you have a problem because you get an output that consists of 400 'x' followed by 400 'o', or the other way around....
Right?

Consider that the scheduler lets each thread run for approx. 10ms unless the thread is preempted by another thread with higher priority that is ready to run.
This means that your threads have plenty of time to write 400 chars to the console, or output window, before the next thread is allowed to run.
This is not a problem in your code or the POSIX thread library, this is how the OS works.

Can you pin-point in a few sentences (less than ten and without code initially) what your undesired behaviour is, you'll get more answers. $Shucks | :-\$
The heading of your post suggests that it's about POSIX threads, but I don't see any problem related to the use of them.

(Just for the record: yes, I've used the POSIX thread library port for Win32.)

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

tiberiuv12-Aug-08 21:08

12-Aug-08 21:08

Thanks for the answer. My desired behavior was to actually see that a separate thread is created and that the output from the thread is intertwined with the output from the main thread. I had the impression i had done this before and it worked (by creating two threads directly from the main function) but it's getting clear to me that this is not the case Smile | :)

And yes, it wasn't a POSIX threads question as much as it was a threading question. But right now it's clear to me what is happening. Thank you. $Shucks | :-\$

Roger Stoltz12-Aug-08 22:33

12-Aug-08 22:33

tiberiuv wrote:
My desired behavior was to actually see that a separate thread is created and that the output from the thread is intertwined with the output from the main thread. I had the impression i had done this before and it worked (by creating two threads directly from the main function) but it's getting clear to me that this is not the case

Well, depends on what you mean by "working".
It does work, in the sense that a new thread will be created with pthread_create().

However, I think you are implementing it in a strange way and mixing Win32, MFC and pthread.
I suggest you read this excellent article[^] to get started with multithreading using the MFC framework and also understand how and when to use multithreading.
The article also helps you avoid common pitfalls. Even though the implementation details may differ from the POSIX thread library, the concept of multithreading is still the same.

The POSIX thread port library adds a lot of limitations to the Win32 API and should, in my opinion, only be used to write code that is supposed to be portable between Win32 and e.g. Linux. One of the worst limitations is that you cannot wait on multiple synchronization objects. Compare with ::WaitForMultipleObjects().
There are also some features of the POSIX thread library that are unsupported in the Win32 port, such as cleanup handlers.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

tiberiuv13-Aug-08 1:48

13-Aug-08 1:48

Ah, damn. I asked this in the wrong place. I'm actually doing this under Linux. No MFC/Visual C++ involved here. Sorry.

tiberiuv14-Aug-08 2:16

14-Aug-08 2:16

I still have one small question, if you do not mind Smile | :)

on the server side i have something like this:

while( pThread->stream->read( recBuff, MAX_LEN) )
{
cout << recBuff;
}

and on the client side i have something like this:

while ( true )
{
  cin >> sendBuff;
  cs->write( sendBuff, MAX_LEN);
}

So when i write a sentence like: "timmy hates guns" on receiving i get it like i would have entered every word followed by a new line. I think that this is just what the client is doing. It's sending each word at a time in rapid succession. For this reason, some words do not pop out at the other end. I can end up with "timmy guns" and so on. Any idea why the client isn't sending the whole sentence? I'm using ::send(socket, (void*)msg, strlen(msg)+1, 0) to send over the network Smile | :)

. Thanks

Roger Stoltz14-Aug-08 2:35

14-Aug-08 2:35

Try using cin.getline() instead of the >> operator since the operator break at least on every whitespace and possibly on every char.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

tiberiuv14-Aug-08 3:26

14-Aug-08 3:26

you my friend, are a genius Smile | :)

Roger Stoltz14-Aug-08 3:33

14-Aug-08 3:33

tiberiuv wrote:
you my friend, are a genius

My most humble thanks.

Glad I could help you.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

Memory allocation

Dennis L12-Aug-08 4:15

12-Aug-08 4:15

Hi every one!

Can any one explain me why is this happening

struct SOME
{
char s0[1];
char s1[2];
char s2[1];
};

int main()
{
SOME *sm = new SOME;
delete sm;
return 0;
}

before allocation (with new)

0xcccccccc
{
s0=0xcccccccc <bad ptr="">
s1=0xcccccccd <bad ptr="">
s2=0xcccccccf <bad ptr="">
}

after allocation

0x00332e98
{
s0=0x00332e98 "
πΊ««««««««ξώξώ"
s1=0x00332e99 "πΊ««««««««ξώξώ"
s2=0x00332e9b "Ί««««««««ξώξώ"
}

after deallocation (with delete)

0x00332e98 <----- Is that a problem?
{
s0=0x00332e98 "" <-----
s1=0x00332e99 "3" <-----
s2=0x00332e9b "" <-----
}

thanks!

David Crow12-Aug-08 4:19

David Crow

12-Aug-08 4:19

I don't see a problem. What specifically are you asking?

"Love people and use things, not love things and use people." - Unknown

"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch

Dennis L12-Aug-08 4:29

12-Aug-08 4:29

first:

in that below, why the memory addresses of s0, s1, s2 are different and has these values

0xcccccccc
{
s0=0xcccccccc <bad ptr="">
s1=0xcccccccd <bad ptr="">
s2=0xcccccccf <bad ptr="">
}

second:

after deallocation the memory addresses are still assigned to s0, s1, s2

0x00332e98
{
s0=0x00332e98 ""
s1=0x00332e99 "3" is that a problem
s2=0x00332e9b ""
}

David Crow12-Aug-08 4:36

David Crow

12-Aug-08 4:36

Dennis L wrote:
in that below, why the memory addresses of s0, s1, s2 are different...

As opposed to all being the same?

Dennis L wrote:
after deallocation the memory addresses are still assigned to s0, s1, s2

And what would you expect them to be? All delete does is tell the memory manager that address 0x00332e98 is available for use again.

"Love people and use things, not love things and use people." - Unknown

"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch

Dennis L12-Aug-08 4:52

12-Aug-08 4:52

first
I have read that all local variables that are not initialized explicitly are being intialiazed to 0xcccccccc with the Microsoft compilers. The first OK but the other two?

second
what happens with this address if the program exits
or

is this

void func1()
{
SOME *sm = new SOME;
delete sm;
}

void func2()
{
func1();
// What happents here?
}

David Crow12-Aug-08 5:18

David Crow

12-Aug-08 5:18

Dennis L wrote:
what happens with this address if the program exits

It is reclaimed by the memory manager.

Dennis L wrote:
// What happents here?

Nothing.

"Love people and use things, not love things and use people." - Unknown

"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch

Dennis L12-Aug-08 5:22

12-Aug-08 5:22

I think i got it now

Thanks for your reply!

Roger Stoltz12-Aug-08 4:41

12-Aug-08 4:41

Dennis L wrote:
Is that a problem?

In short: no, unless you're trying to use it.

The fact that you have released the memory you previously allocated does not make the pointer to point somewhere else. The memory should not be used after being deallocated since it may contain invalid data as you've instructed the memory manager that you don't need it any longer by deallocating it.

This is why it's considered best practice to assign NULL to pointers you've deallocated to be able to test on the pointer to see if you can use the memory it points to.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

sashoalm12-Aug-08 4:48

sashoalm

12-Aug-08 4:48

Dennis L wrote:

Can any one explain me why is this happening

...

before allocation (with new)

0xcccccccc
{
s0=0xcccccccc
s1=0xcccccccd
s2=0xcccccccf
}

It's for debugging purposes I think - this way it's easier to detect if you're using your data before you've initialized it.

There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal