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
Pretty sure they don't have anything like that built in. You better start looking into EnterCriticalSection()/LeaveCriticalSection().Anybody knows if WriteFile and ReadFile have some kind of mutual exclusion or use different streams maybe.
The crows maintain that a single crow could destroy the heavens. Doubtless this is so. But it proves nothing against the heavens, for the heavens signify simply: the impossibility of crows.
Perhaps reading the manual page further than getting the parameters right would be of some use.
Hmm,
I was looking at
and I was wondering if the handle fd that I get when I open the serial port fromCode:void InitializeCriticalSection(LPCRITICAL_SECTION lpCriticalSection);
could be used as the lpCriticalSection parameter. In general can any pointer be used as lpCriticalSection? Thanks,Code:*fd = CreateFile(portname,GENERIC_READ|GENERIC_WRITE,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
Amish
No, you need to pass a pointer to a CRITICAL_SECTION structure.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Alright got it. I managed to make it workOriginally Posted by CornedBee
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.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
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
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.Code:Do not use the SuspendThread function
The crows maintain that a single crow could destroy the heavens. Doubtless this is so. But it proves nothing against the heavens, for the heavens signify simply: the impossibility of crows.
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.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
