Mutual exclusion with threads

Hi,
I am writing a driver for a hardware that uses the serial port. I have 1 thread that write to the serial port using WriteFile() and one that reads from it using ReadFile().
Since they are using the same handle to the serial port, I am afraid, they might mess each other's data. Anybody knows if WriteFile and ReadFile have some kind of mutual exclusion or use different streams maybe. Thanks
Amish

Quote:

---

Anybody knows if WriteFile and ReadFile have some kind of mutual exclusion or use different streams maybe.

---

Pretty sure they don't have anything like that built in. You better start looking into EnterCriticalSection()/LeaveCriticalSection().

Perhaps reading the manual page further than getting the parameters right would be of some use.

Hmm,
I was looking at

Code:

---

void InitializeCriticalSection(LPCRITICAL_SECTION lpCriticalSection);

---

and I was wondering if the handle fd that I get when I open the serial port from

Code:

---

*fd = CreateFile(portname,GENERIC_READ|GENERIC_WRITE,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);

---

could be used as the lpCriticalSection parameter. In general can any pointer be used as lpCriticalSection? Thanks,
Amish

No, you need to pass a pointer to a CRITICAL_SECTION structure.

Quote:

---

Originally Posted by CornedBee

No, you need to pass a pointer to a CRITICAL_SECTION structure.

---

Alright got it. I managed to make it work :( Got some problems related to static functions. Just a note for other people watching this thread. The thread entry point function needs to be static and declared outside of the class declaration in the .h file. I don't know if this is different in different compilers but I am using MSVC++.

I was curious about the SuspendThread feature. Let's say a function such as ReadFile is happening in my thread A and another thread B calls SuspendThread on A. Will the ReadFile be allowed to finish before the thread is suspended? Thanks for any insight,
Amish

That's the same in all compilers. Global and member functions are different.
On the other hand, you may pass a static member - not that it helps you much.

Regarding the suspension issue, it depends what you mean by "finish". The function won't return, but the I/O operation may yet be performed - but only as long as there's no code intervention needed, i.e. if an I/O request has been sent to the hard disk, it will satisfy the request, but the thread will not make any use whatsoever of the data until it is resumed.
I think.

Doing some test on the code showed that the ReadFile() actually blocked the I/O and if the writeThread suspended the readThread and then called WriteFile(), it waited indefinitly probably for ReadFile() to finish. I decided to use a variable that got set in the writeThread before it starts to use WriteFile. If the readThread sees the variable is set, it will not call ReadFile and sleep for 1 second. It seems to give enough time for my readThread to "Capture" the I/O stream for it's purpose. Thanks for all your answers
Amish

Do not use the SuspendThread function

Code:

---

Do not use the SuspendThread function

---

I know this doesn't exactly apply, but sometimes it is useful to start a process via CreateProcess with the main thread suspended (one of the CreateProcess API options), so that, for instance, you can add the handle to the process to a kernel job object before the process actually does anything. Then you resume the thread via the handle in the PROCESS_INFORMATION structure. I guess that doesn't exactly count as using the SuspendThread function, but it does show that sometimes suspending a thread is useful.

The idea is that you should never suspend a running thread, because you can't know what resources it's currently holding, and thus what other threads it blocks - it might block the thread that's supposed to resume it.

Creating a thread in suspended state is different, because you know it can't possibly hold any resources.