Critical Section/Mutex/Multiple Threads

[sandyrhu]

Hi All,

I'm tring to write a C++ application. It has a message reader which has critical section protected memory using a Mutex. I will have four producers (using threads) that will take a keyboard input and pass the input to the Message Reader critical section memory. This is a coursework I've to do and am a bit stuck on how to make this work.

My plan was to create the critical section memory in the reader source file. What I don't know is how to have another source file grab the mutex and be able to write to the critical section memory, but in different source files. How do I link the two together? Would be great if somebody could point me in the right direction. Thanks in advance for any help.

[dude_1967]

sandy,

Well we can't do the assignment for you. That takes all the fun out of it. But let's get started.

This assignment can be broken down into a few simple parts.

1) The shared critical data section.
2) The thread synchronization.
3) The thread architecture and associated functionality.

Your questions relate to 1) and 2) so let's start there.

For 1) you should simply define a data section outside of all functions in a single C++ file. This data can be made visible to the threads in other files by using the extern keyword.



// In a single C++ file
BYTE shared_data[128];

// In another C++ file
extern BYTE shared_data[128];



Now all of the files can access shared_data.

For 2) I would recommend using a so-called critical section instead of a mutex. Assuming that you are using Microsoft compilers. You need to initialize it once only, use it throughout the program with Enter/Leave, and delete it once upon program termination. For this, you will need the following functions:



InitializeCriticalSection(...)
DeleteCriticalSection(...)

EnterCriticalSection(...)
LeaveCriticalSection(...)



This should be enough to give you some ideas on getting started.
Ask detailed questions as you proceed with the assignment.

If you really must use a mutex, then that's possible too.

Good luck.

Sincerely, Chris.

:thumb:

[sandyrhu]

Thanks for that Chris. I'll have a go at that tonight and see how I get on. It's good to know that a separate source file is what's required. I'd been thinking that I could code all the mutex stuff within the reader file. One question, can you give me any clues on how to link them together - do I need to make the memory file a header file or anything special? Or can I simply reference the same area of memory from the producer, pulse an event in the memory CS file, and the reader will then (using the same memory reference) read the memory contents? Forgot to say, that it must be a mutex I use, I assume that a mutex works well with a critical section? Or is it a different animal altogether?

I'd like to thank you very much indeed for your kind response and I agree totally, too much code would spoil the fun - and I'd learn nothing either!

I'll let you know how it's going

Hopefully hear soon

Sandy

[dude_1967]

sandy,

Got a few basic questions:

What development environment are you using (Compiler, GUI, etc.)?

Are the critical data supposed to be in memory or in a shared file?

Sincerely, Chris.

:thumb:

[sandyrhu]

Hi Chris,

Am using visual studio net 2003 and will have a console window to input the data for the message producers. The data is to be sent from the producer (there will be four) into shared memory. As the producers could theoretically access the memory at the same time have been told to protect it using mutex.

Hope this helps

thanks

Sandy

[dude_1967]

OK.

That doesn't sound too bad.

And I forgot to ask earlier: In what language will you be writing: C++, C, C#, or something else?

Chris.

:thumb:

[sandyrhu]

Will be writing in C++.

[dude_1967]

Break up the problem.

1) Set up a console application in C++ using VC.NET 2003. Do not use managed C++. Do not use any managed extensions. This environment will set up a nice workspace for you. The only confusino is that I think it will probably set up some files which includes stdafx.h and it will map main to _tmain or some other things like that, but that's OK.

2) At first just use one file.

3) Set up your critical data array in the file outside of all subroutines.

4) Set up your threads and thread architecture as well as the algorithms dealing with the access to the shared data region. At this stage just leave the data unprotected by mutexes.

5) Get everything working without using a mutex. This is probably half the battle or more.

6) Finally, with everything up and running, integrate the mutex for shared access to the data.

Look for another post from me in which I recommend a popular book on Windows programming. Maybe you should take a look at this book on the chapters on threads and synchronization.

Oh. Here is the link to the other thread. The literature suggestion is in my first response: http://www.codeguru.com/forum/showthread.php?threadid=286904

Good luck.

Sincerely, Chris.

:thumb:

[sandyrhu]

Chris,

Just to thank you for your help. Have now completed the project with 4 producers and 1 reader. I used shared memory buffers within the reader and protected it with a mutex, each producer fights for the mutex. Now I've completed this I really feel that I've learned a lot. (I still prefer coding in Java though LOL!).

Anyway, was just a post to say thanks

[Andreas Masur]

[Moved thread]

[Giordano]

Hi, Sandy.
Just a tip.
Several weeks ago I wrote a chunk of code in multithreading environment that used the semaphore to protect the critical section.

I found out a good tool that has advanced options to manage the opened by the application synchronization objects (semaphores, mutants, etc...) and threads.

The tool name is XTM and you can find it in
http://www.warecase.com/Downloads.asp

Hope it will help you.

Auguri!

[Sam Hobbs]

Originally posted by Giordano

The tool name is XTM and you can find it in It should be noted that it is commercial software; a single-user license is $69.

Since in this situation the project is coursework, a tool is unlikely to be relevant.

I am not sure what the relevant forum rules are, but I think you should reveiew them to ensure you don't violate them in the future. I am not a moderator so I will leave this for them.