Thread: [Dev-C++] how to update data constantly?

My whole projects have two thread.
one thread is reading RS-232 communication port.
another thread is Win32 GUI to display the data got from RS-232
communication port.

The design I had is:
Buttons on Win32 GUI.
So when the button is clicked, the corresponding data is read from RS232
thread, and display in the GUI thread.

BUT I want to have a constantly updated display.  That is, there is NO
button to trigger the data update.
When the data of RS232 thread is updated, my display of GUI thread need to
be updated.
What should I design?

My consideration for the design is:
add a constant interval timer to trigger the data update.
but how to implement it?
and do you have any other good idea?

On Dec 5, 2007 1:10 PM, Jessica Chen <jes...@gm...> wrote:
> My whole projects have two thread.
> one thread is reading RS-232 communication port.
> another thread is Win32 GUI to display the data got from RS-232
> communication port.
>
> The design I had is:
> Buttons on Win32 GUI.
> So when the button is clicked, the corresponding data is read from RS232
> thread, and display in the GUI thread.
>
> BUT I want to have a constantly updated display.  That is, there is NO
> button to trigger the data update.
> When the data of RS232 thread is updated, my display of GUI thread need to
> be updated.
> What should I design?
>
> My consideration for the design is:
> add a constant interval timer to trigger the data update.
>  but how to implement it?
> and do you have any other good idea?

A commonly used technique is to have the GUI thread check the reader
thread every X miliseconds.  This requires that you use a mutex to
lock the data while it's being read, otherwise you might incur the
wrath of undefined behavior when reading memory that's currently being
written to.

What if you had a dual-core CPU, and you managed to send a read
request exactly when you sent a write request?  Something tells me
that's not possible because of the mutexes in the lower-level
implementation, but it would be interesting to see which request the
memory controller disregards.


I'm not sure how to implement a mutex in a Win32 thread, however,
pthreads is only a wrapper on top of Win32, so it can be done (I
didn't notice any special code in the pthreads sources when I glossed
over them).

-- 
Registered Linux Addict #431495
http://profile.xfire.com/mrstalinman
John 3:16!
If Microsoft is the Wal*Mart of the Software World, then Linux is the Home Depot

A cheaper form of mutex for Win32 applications are the critical
sections. In some situations a semaphore may be suitable.

/pwm

On Wed, 5 Dec 2007, Chris Miller wrote:

> On Dec 5, 2007 1:10 PM, Jessica Chen <jes...@gm...> wrote:
> > My whole projects have two thread.
> > one thread is reading RS-232 communication port.
> > another thread is Win32 GUI to display the data got from RS-232
> > communication port.
> >
> > The design I had is:
> > Buttons on Win32 GUI.
> > So when the button is clicked, the corresponding data is read from RS232
> > thread, and display in the GUI thread.
> >
> > BUT I want to have a constantly updated display.  That is, there is NO
> > button to trigger the data update.
> > When the data of RS232 thread is updated, my display of GUI thread need to
> > be updated.
> > What should I design?
> >
> > My consideration for the design is:
> > add a constant interval timer to trigger the data update.
> >  but how to implement it?
> > and do you have any other good idea?
>
> A commonly used technique is to have the GUI thread check the reader
> thread every X miliseconds.  This requires that you use a mutex to
> lock the data while it's being read, otherwise you might incur the
> wrath of undefined behavior when reading memory that's currently being
> written to.
>
> What if you had a dual-core CPU, and you managed to send a read
> request exactly when you sent a write request?  Something tells me
> that's not possible because of the mutexes in the lower-level
> implementation, but it would be interesting to see which request the
> memory controller disregards.
>
>
> I'm not sure how to implement a mutex in a Win32 thread, however,
> pthreads is only a wrapper on top of Win32, so it can be done (I
> didn't notice any special code in the pthreads sources when I glossed
> over them).
>
> --
> Registered Linux Addict #431495
> http://profile.xfire.com/mrstalinman
> John 3:16!
> If Microsoft is the Wal*Mart of the Software World, then Linux is the Home Depot
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

I don't understand this point.
I think a cheaper form of semaphore (whatever for Win32 application or Unix
application) is mutex.
A critical section is a piece of code which access a shared resource (like
data) of two threads.

Can you pls do a bit more explanation about your issue?

On Dec 6, 2007 5:43 AM, Per Westermark <pw...@ia...> wrote:

> A cheaper form of mutex for Win32 applications are the critical
> sections. In some situations a semaphore may be suitable.
>
> /pwm
>
> On Wed, 5 Dec 2007, Chris Miller wrote:
>
> > On Dec 5, 2007 1:10 PM, Jessica Chen <jes...@gm...> wrote:
> > > My whole projects have two thread.
> > > one thread is reading RS-232 communication port.
> > > another thread is Win32 GUI to display the data got from RS-232
> > > communication port.
> > >
> > > The design I had is:
> > > Buttons on Win32 GUI.
> > > So when the button is clicked, the corresponding data is read from
> RS232
> > > thread, and display in the GUI thread.
> > >
> > > BUT I want to have a constantly updated display.  That is, there is NO
> > > button to trigger the data update.
> > > When the data of RS232 thread is updated, my display of GUI thread
> need to
> > > be updated.
> > > What should I design?
> > >
> > > My consideration for the design is:
> > > add a constant interval timer to trigger the data update.
> > >  but how to implement it?
> > > and do you have any other good idea?
> >
> > A commonly used technique is to have the GUI thread check the reader
> > thread every X miliseconds.  This requires that you use a mutex to
> > lock the data while it's being read, otherwise you might incur the
> > wrath of undefined behavior when reading memory that's currently being
> > written to.
> >
> > What if you had a dual-core CPU, and you managed to send a read
> > request exactly when you sent a write request?  Something tells me
> > that's not possible because of the mutexes in the lower-level
> > implementation, but it would be interesting to see which request the
> > memory controller disregards.
> >
> >
> > I'm not sure how to implement a mutex in a Win32 thread, however,
> > pthreads is only a wrapper on top of Win32, so it can be done (I
> > didn't notice any special code in the pthreads sources when I glossed
> > over them).
> >
> > --
> > Registered Linux Addict #431495
> > http://profile.xfire.com/mrstalinman
> > John 3:16!
> > If Microsoft is the Wal*Mart of the Software World, then Linux is the
> Home Depot
> >
> >
> -------------------------------------------------------------------------
> > SF.Net email is sponsored by: The Future of Linux Business White Paper
> > from Novell.  From the desktop to the data center, Linux is going
> > mainstream.  Let it simplify your IT future.
> > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> > _______________________________________________
> > Dev-cpp-users mailing list
> > Dev...@li...
> > TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >
>
>

Hey, Chris,

  I think you really don't need to consider if it is dual-core or not.  Just
think it as one processor when you write code.  The requests write or read,
either one won't be disregards by  memory controller.  The OS will arrange
this.  I mean, low level software controls the sequence, not hardware
itself.

  I used to use 4-core processor (a kind of SOC, system on a chip).  Its OS
provides me the interface of which I (users) can control the each core of
the processor.  So I(user) can decide which one I want to process first,
either write request or read request.

Thanks,
Jessica


--What if you had a dual-core CPU, and you managed to send a read
request exactly when you sent a write request?  Something tells me
that's not possible because of the mutexes in the lower-level
implementation, but it would be interesting to see which request the
memory controller disregards.

On Dec 5, 2007 5:32 PM, Chris Miller <lor...@gm...> wrote:

> On Dec 5, 2007 1:10 PM, Jessica Chen <jes...@gm...> wrote:
> > My whole projects have two thread.
> > one thread is reading RS-232 communication port.
> > another thread is Win32 GUI to display the data got from RS-232
> > communication port.
> >
> > The design I had is:
> > Buttons on Win32 GUI.
> > So when the button is clicked, the corresponding data is read from RS232
> > thread, and display in the GUI thread.
> >
> > BUT I want to have a constantly updated display.  That is, there is NO
> > button to trigger the data update.
> > When the data of RS232 thread is updated, my display of GUI thread need
> to
> > be updated.
> > What should I design?
> >
> > My consideration for the design is:
> > add a constant interval timer to trigger the data update.
> >  but how to implement it?
> > and do you have any other good idea?
>
> A commonly used technique is to have the GUI thread check the reader
> thread every X miliseconds.  This requires that you use a mutex to
> lock the data while it's being read, otherwise you might incur the
> wrath of undefined behavior when reading memory that's currently being
> written to.
>
> What if you had a dual-core CPU, and you managed to send a read
> request exactly when you sent a write request?  Something tells me
> that's not possible because of the mutexes in the lower-level
> implementation, but it would be interesting to see which request the
> memory controller disregards.
>
>
> I'm not sure how to implement a mutex in a Win32 thread, however,
> pthreads is only a wrapper on top of Win32, so it can be done (I
> didn't notice any special code in the pthreads sources when I glossed
> over them).
>
> --
> Registered Linux Addict #431495
> http://profile.xfire.com/mrstalinman
> John 3:16!
> If Microsoft is the Wal*Mart of the Software World, then Linux is the Home
> Depot
>

One alternative is to let the RS232 thread send messages to the GUI
thread. Either with the serial data, or just as information that there are
serial data available.

/pwm

On Wed, 5 Dec 2007, Jessica Chen wrote:

> My whole projects have two thread.
> one thread is reading RS-232 communication port.
> another thread is Win32 GUI to display the data got from RS-232
> communication port.
>
> The design I had is:
> Buttons on Win32 GUI.
> So when the button is clicked, the corresponding data is read from RS232
> thread, and display in the GUI thread.
>
> BUT I want to have a constantly updated display.  That is, there is NO
> button to trigger the data update.
> When the data of RS232 thread is updated, my display of GUI thread need to
> be updated.
> What should I design?
>
> My consideration for the design is:
> add a constant interval timer to trigger the data update.
> but how to implement it?
> and do you have any other good idea?
>

On Dec 6, 2007 2:41 AM, Per Westermark <pw...@ia...> wrote:
> One alternative is to let the RS232 thread send messages to the GUI
> thread. Either with the serial data, or just as information that there are
> serial data available.
>
> /pwm

I would like to note that this does have a significant drawback.

If you have to update the GUI every time something happens, it has a
tendency to lag in a big way.

You can alleviate this by only updating every X updates, however, this
adds a problem of constantly checking whether or not the update
threshold has been reached.  It's far simpler to use the mutex
approach, even though it is slightly more difficult to implement and
harder to understand (if you're not familiar with it).

Once I tried having the working thread update the GUI in Java....
locked up the whole GUI during operation, so if you wanted to kill it
you'd have to kill the running JVM - not fun!

-- 
Registered Linux Addict #431495
http://profile.xfire.com/mrstalinman
John 3:16!
If Microsoft is the Wal*Mart of the Software World, then Linux is the Home Depot

Hi all,

  Well, I must say that this thread really interests me. Could we have a 
look at your query code for the RS232 device?



>From: "Chris Miller" <lor...@gm...>
>To: "Per Westermark" <pw...@ia...>
>CC: dev...@li...
>Subject: Re: [Dev-C++] how to update data constantly?
>Date: Thu, 6 Dec 2007 14:49:32 -0800
>
>On Dec 6, 2007 2:41 AM, Per Westermark <pw...@ia...> wrote:
> > One alternative is to let the RS232 thread send messages to the GUI
> > thread. Either with the serial data, or just as information that there 
>are
> > serial data available.
> >
> > /pwm
>
>I would like to note that this does have a significant drawback.
>
>If you have to update the GUI every time something happens, it has a
>tendency to lag in a big way.
>
>You can alleviate this by only updating every X updates, however, this
>adds a problem of constantly checking whether or not the update
>threshold has been reached.  It's far simpler to use the mutex
>approach, even though it is slightly more difficult to implement and
>harder to understand (if you're not familiar with it).
>
>Once I tried having the working thread update the GUI in Java....
>locked up the whole GUI during operation, so if you wanted to kill it
>you'd have to kill the running JVM - not fun!
>
>--
>Registered Linux Addict #431495
>http://profile.xfire.com/mrstalinman
>John 3:16!
>If Microsoft is the Wal*Mart of the Software World, then Linux is the Home 
>Depot
>
>-------------------------------------------------------------------------
>SF.Net email is sponsored by:
>Check out the new SourceForge.net Marketplace.
>It's the best place to buy or sell services for
>just about anything Open Source.
>http://sourceforge.net/services/buy/index.php
>_______________________________________________
>Dev-cpp-users mailing list
>Dev...@li...
>TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

_________________________________________________________________
Transfira JÁ a última versão do Windows Live Messenger! 
http://get.live.com/pt-pt/messenger/overview

The RS232 API in Windows supports event-driven processing. You can get an
event when a receive buffer is full, a specific 'match' character is
received or there has been a timeout between two characters.

A match character is maningful to catch a line-break in ASCII protocols,
or the end-of-message byte in a binary protocol.

You normally don't let the RS232 thread process characters one at a time,
so you normally don't generate an update event every character. When
implementing a chat, the RS232 code will normally trig on the pause
between individual characters, resulting in a character-at-a-time update
of the GUI. If the user pastes a large block of text, the serial driver
will instead generate events based on serial buffer size with an optional
time-out event after the paste. Is the receive buffer large enough, the
paste will only result in a single timeout event, i.e. a single GUI
update.

A computer-driven communication will on the other hand trig on buffer-full
events or the end-of-message event from the filter character, and allowing
updates of the GUI a message at a time or a full serial buffer at a time.
For this kind of communication, the GUI would normally not display actual
data, but instead transfer statistics, i.e. # of packets, # of bytes, # of
resends or similar.

In the end, there will normally not be a problem with a dying GUI
overloaded by more and more cached events, since the amount of events
will normally be limited by the RS232 configuration. A correct
implementation of the GUI would also make use of PeekMessage() whenever
it receives an update event but before it performs the updating. This
allows multiple pending update events to only result in a single screen
redraw.

A message-based solution will consume zero processing power when the
serial channel is idle, and will generate redraw load corresponding to
buffer size, timeout and end-of-message intervals when data is arriving.

/pwm

On Thu, 6 Dec 2007, Chris Miller wrote:

> On Dec 6, 2007 2:41 AM, Per Westermark <pw...@ia...> wrote:
> > One alternative is to let the RS232 thread send messages to the GUI
> > thread. Either with the serial data, or just as information that there are
> > serial data available.
> >
> > /pwm
>
> I would like to note that this does have a significant drawback.
>
> If you have to update the GUI every time something happens, it has a
> tendency to lag in a big way.
>
> You can alleviate this by only updating every X updates, however, this
> adds a problem of constantly checking whether or not the update
> threshold has been reached.  It's far simpler to use the mutex
> approach, even though it is slightly more difficult to implement and
> harder to understand (if you're not familiar with it).
>
> Once I tried having the working thread update the GUI in Java....
> locked up the whole GUI during operation, so if you wanted to kill it
> you'd have to kill the running JVM - not fun!
>
> --
> Registered Linux Addict #431495
> http://profile.xfire.com/mrstalinman
> John 3:16!
> If Microsoft is the Wal*Mart of the Software World, then Linux is the Home Depot
>

Thanks, Chris.

Your way of "A commonly used technique is to have the GUI thread check the
reader
thread every X miliseconds." works fine in my project.

 Do mutex in win32 API is as follows:
thread 1:
//      wait_result = WaitForSingleObject(hMutex, 1000);
//
//      if (wait_result == WAIT_OBJECT_0)
//      {
//           // data processing: data need to be copied from local to shared
area.  <-----
//           ReleaseMutex(hMutex);
//      }
//      else
//     {
//          // error
//     }

thread 2:
//      wait_result = WaitForSingleObject(hMutex, 1000);
//
//      if (wait_result == WAIT_OBJECT_0)
//      {
//           // data processing: data need to be copied from shared data to
local area.  <--------
//           ReleaseMutex(hMutex);
//      }
//      else
//     {
//          // error
//     }
On Dec 5, 2007 5:32 PM, Chris Miller <lor...@gm...> wrote:

> On Dec 5, 2007 1:10 PM, Jessica Chen <jes...@gm...> wrote:
> > My whole projects have two thread.
> > one thread is reading RS-232 communication port.
> > another thread is Win32 GUI to display the data got from RS-232
> > communication port.
> >
> > The design I had is:
> > Buttons on Win32 GUI.
> > So when the button is clicked, the corresponding data is read from RS232
> > thread, and display in the GUI thread.
> >
> > BUT I want to have a constantly updated display.  That is, there is NO
> > button to trigger the data update.
> > When the data of RS232 thread is updated, my display of GUI thread need
> to
> > be updated.
> > What should I design?
> >
> > My consideration for the design is:
> > add a constant interval timer to trigger the data update.
> >  but how to implement it?
> > and do you have any other good idea?
>
> A commonly used technique is to have the GUI thread check the reader
> thread every X miliseconds.  This requires that you use a mutex to
> lock the data while it's being read, otherwise you might incur the
> wrath of undefined behavior when reading memory that's currently being
> written to.
>
> What if you had a dual-core CPU, and you managed to send a read
> request exactly when you sent a write request?  Something tells me
> that's not possible because of the mutexes in the lower-level
> implementation, but it would be interesting to see which request the
> memory controller disregards.
>
>
> I'm not sure how to implement a mutex in a Win32 thread, however,
> pthreads is only a wrapper on top of Win32, so it can be done (I
> didn't notice any special code in the pthreads sources when I glossed
> over them).
>
> --
> Registered Linux Addict #431495
> http://profile.xfire.com/mrstalinman
> John 3:16!
> If Microsoft is the Wal*Mart of the Software World, then Linux is the Home
> Depot
>

On Dec 6, 2007 8:41 AM, Jessica Chen <jes...@gm...> wrote:
> Thanks, Chris.
>
> Your way of "A commonly used technique is to have the GUI thread check the
> reader
> thread every X miliseconds." works fine in my project.

Hey, worked fine in Java, why can't it work in C++?

Glad it worked!

-- 
Registered Linux Addict #431495
http://profile.xfire.com/mrstalinman
John 3:16!
If Microsoft is the Wal*Mart of the Software World, then Linux is the Home Depot

Thanks so much, Rafael.

I think I understand your method to solve the problem what I met.
And I believe this method can help me solve the problem.
But it is a little bit difficult.
I mean, for the whole code structure, you need one more thread to trigger my
GUI code.
Then the whole structure of the project is not that reasonable.  :-)

Your idea is based on "Singal Triggered".  It belongs to the design of
CPU-bound system.
(As my understanding, CPU-bound system triggers events by signals.)
But unfortunately, it seems Win32 API GUI design is I/O bound system.
(As my understanding, I/O bound system triggers events by I/O input, like
buttons.)
Your consideration is still great and classic, specially when using
CPU-bound system.

Now I am using Chris' way to solve my problem.
"A commonly used technique is to have the GUI thread check the reader
thread every X miliseconds."

BTW, I am new in the area of Win32 API programming.  Anything wrong/unclear,
pls let me know.

On Dec 6, 2007 11:44 AM, Chris Miller <lor...@gm...> wrote:

> On Dec 6, 2007 8:41 AM, Jessica Chen <jes...@gm...> wrote:
> > Thanks, Chris.
> >
> > Your way of "A commonly used technique is to have the GUI thread check
> the
> > reader
> > thread every X miliseconds." works fine in my project.
>
> Hey, worked fine in Java, why can't it work in C++?
>
> Glad it worked!
>
> --
> Registered Linux Addict #431495
> http://profile.xfire.com/mrstalinman
> John 3:16!
> If Microsoft is the Wal*Mart of the Software World, then Linux is the Home
> Depot
>