No context switch between Threads and parent ?

[wysota]

I can say one thing - your multi-thread design is full of flaws First of all you access the same object from within more than one thread which is a Bad Thing (TM). Second of all all events for the serial object of yours will be processed in the main thread. I don't know if you actually use events there but based on what you observe, it is highly possible.

My first and most basic question is - are you sure you really need separate threads for the communication?

[donglebob]

First of all you access the same object from within more than one thread which is a Bad Thing

Maybe I should swap the design. The Threads will get the parent and the serial-classs will be shared between both.
I must use two threads because of two way communication (overlapped/asynchrone).
I think that it is common to do it like that in rs232 communication.

Here you see an example of MS
http://msdn.microsoft.com/en-us/library/ms810467.aspx

......a user interface thread that does memory management, a writer thread that controls all writing, and a reader/status thread that reads data and handles status changes on the port.

Second of all all events for the serial object of yours will be processed in the main thread. I don't know if you actually use events there but based on what you observe, it is highly possible

I worried about that. I think swapping would solve this?
All the access from the threads to the serial-class would be done in the thread context.

The threads must share just one thing, tha object of the foreign serial library, because this includes all stuff to access com-port.
Btw, i use this
http://www.codeproject.com/KB/system/serial.aspx

[wysota]

I must use two threads because of two way communication (overlapped/asynchrone).

If you use non-blocking IO, you don't have to have any separate threads.

I think that it is common to do it like that in rs232 communication.

Common doesn't yet mean correct. Java programmers use a lot of multithreading, so it's common, although in most cases unnecessary when brought to different grounds.

I worried about that. I think swapping would solve this?

Swapping in what way?

The threads must share just one thing, tha object of the foreign serial library, because this includes all stuff to access com-port.
Btw, i use this
http://www.codeproject.com/KB/system/serial.aspx

Have you tried QExtSerialPort?

[donglebob]

hi,

If you use non-blocking IO, you don't have to have any separate threads.

When I use there functions like "WaitForMultipleObjects", where the reader thread must wait for some events like "data arrived" or sth. like that, it will block the thread until data is available.
Meanwhile my writer thread could do some IO operations. Thats the reason why I need two threads.

Swapping in what way?

Now my threads are children of the the serial-class and they use the pointer of parent to execute parent-functions.
When I switch parent to children and children to parent, every access to serial-class-object would run in the threads context and not in the main-app.

Have you tried QExtSerialPort?

Yes, but it just allows blocking IO. overlapped IO is not implemented yet.

[wysota]

When I use there functions like "WaitForMultipleObjects", where the reader thread must wait for some events like "data arrived" or sth. like that, it will block the thread until data is available.
Meanwhile my writer thread could do some IO operations. Thats the reason why I need two threads.

Ok, but why block at all?

Yes, but it just allows blocking IO. overlapped IO is not implemented yet.

Not really. You can check bytesAvailable() and do read() only when there is something to read. In that case it returns immediately. Actually I think it will return immediately regardless if there is anything to read (I'm not sure of that though).

[donglebob]

Ok, but why block at all?

Uhmm, thats how WaitForMultipleObject works ?!?!
In the samples of MS, which I read, it was always blocked like this.
I have to wait for events...and if i understood it right the thread must wait somwhere and proceed after the wanted event arrived, to read the data etc... (data can be read immediately or with pending = while pending WaitFor......)

http://msdn.microsoft.com/en-us/libr...#serial_topic4

Not really. You can check bytesAvailable() and do read() only when there is something to read. In that case it returns immediately. Actually I think it will return immediately regardless if there is anything to read (I'm not sure of that though).

As far as I know access to com at "same time" is not allowed in Qextserialport.
Checked the source again.
In Win32 it open com-port always with the last parameter NULL, that means
non-overlapped (synchrone) access.

[wysota]

Uhmm, thats how WaitForMultipleObject works ?!?!

Ok, but what is the practical reason of doing that? You can use asynchronous communication instead - no blocking, no problems.

As far as I know access to com at "same time" is not allowed in Qextserialport.
Checked the source again.
In Win32 it open com-port always with the last parameter NULL, that means
non-overlapped (synchrone) access.

But you only read if there is anything to read thus the call returns at once effectively making it asynchronous (although in theory it is still synchronous). I assure you you can read and write to the port "at the same time". In practice it is not "the same time" as you're using a single thread so you can either read or write because of a single flow, but you can do one immediately after the other. I assure you this works just fine in many-many applications out there.

Qt does most of it's I/O in buffered mode making it possible for your application to be even more "asynchronous". I don't exactly know how QExtSerialPort is implemented (I'm not very impressed with its quality) but it is known to work so I don't see a reason not to use it. The only thing that sucks with it is the necessity of using timers to poll the port. I've been meaning to fix this myself but currently I don't have time

[donglebob]

hi,

You know I want to use that overlapped IO....and have written the whole sing for that
It would make me cry to throw all of it away

Ok, but what is the practical reason of doing that? You can use asynchronous communication instead - no blocking, no problems.

I think i am using asynchronous comm. with a little break :-)
Ok maybe I misunderstood sth. How should I inform my thread that there is data? (without using WaitforMultipleObjects)

I have to react when an event arrives, so I can read from the port.
Is there another way without WaitFor.......?

[wysota]

Use a timer and check bytesAvailable() periodically. It's a bit dirty solution but tends to be acceptable in this case. If you want to synchronize threads, use the API Qt provides instead of the native one. In many cases it will be much faster. WaitForMultipleObjects() is an equivalent of a semaphore. Use QWaitCondition or similar instead.

[donglebob]

timer is a real dirty sollution. and doing like this sounds like polling with small breaks. thats what i want to/should avoid. I want to do that event-driven.

I think i will keep using WaitFor..... and the two threads...
but i must think on how two give both threads the ability to use the "foreign serial lib instance" to access the port.

Have to sleep one night..and maybe I will get an idea while sleeping

[wysota]

timer is a real dirty sollution. and doing like this sounds like polling with small breaks. thats what i want to/should avoid. I want to do that event-driven.

If you expect data to be available very often then this is fine as most of the time the poll will end up positive. If you expect data to be rare, then increase the timeout. Or use an adaptive timeout...