Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: Best Practices for Updating Threads to Replace Suspend / Resume


This question is answered.


Permlink Replies: 5 - Last Post: Feb 23, 2016 10:58 AM Last Post By: Richard Zarr
Richard Zarr

Posts: 74
Registered: 7/1/98
Best Practices for Updating Threads to Replace Suspend / Resume  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 18, 2016 10:57 AM
This is a question regarding porting from an earlier (pre-deprecated Suspend/Resume) to RAD Studio 2010 Seattle. We have roughly 1M lines of code, that utilize various TThread classes. Our usual 'execute' override ends with a 'if not Terminated then Suspend. Other routines that feed that thread utilize Resume following the updated structures so the thread can operate on them. We also utilize events and WaitForSingleObject for synchronizing the threads... should we consider replacing the Suspend commands with events or some other synchronization method to be compliant going forward? If so, can someone provide an example of a best practice. Thanks!
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Best Practices for Updating Threads to Replace Suspend / Resume
Helpful
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 18, 2016 11:19 AM   in response to: Richard Zarr in response to: Richard Zarr
Richard wrote:

should we consider replacing the Suspend commands with events or
some other synchronization method to be compliant going forward?

Yes. You can use an event. "Suspend" the thread by making it wait on the
event, and then "resume" the thread by signaling the event when ready.

--
Remy Lebeau (TeamB)
Alex Belo

Posts: 626
Registered: 10/8/06
Re: Best Practices for Updating Threads to Replace Suspend / Resume
Helpful
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 18, 2016 11:29 AM   in response to: Richard Zarr in response to: Richard Zarr
Richard Zarr wrote:

Our usual 'execute'
override ends with a 'if not Terminated then Suspend. Other routines
that feed that thread utilize Resume following the updated structures
so the thread can operate on them.

Main problem of Suspend/Resume methods is: they are not thread-safe!
(And this fact was the main reason for introducing Start.)

Counting transitions from resumed to suspended state in these methods
can lead to races and ruin logic of suspending/resuming of thread.

We also utilize events and WaitForSingleObject for synchronizing the
threads...
should we consider replacing the Suspend commands with events or some
other synchronization method to be compliant going forward?

Yes, in general.

You can continue using Suspend/Resume (ignoring the fact that MS
positions them as debugging tool only) if you EXACTLY know that they do
not work at the same time.

--
Alex
David Millington

Posts: 257
Registered: 5/29/05
Re: Best Practices for Updating Threads to Replace Suspend / Resume
Correct
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 18, 2016 11:38 AM   in response to: Richard Zarr in response to: Richard Zarr
On 2016-02-18 18:57:04 +0000, Richard Zarr said:

This is a question regarding porting from an earlier (pre-deprecated
Suspend/Resume) to RAD Studio 2010 Seattle. We have roughly 1M lines
of code, that utilize various TThread classes. Our usual 'execute'
override ends with a 'if not Terminated then Suspend. Other routines
that feed that thread utilize Resume following the updated structures
so the thread can operate on them. We also utilize events and
WaitForSingleObject for synchronizing the threads... should we consider
replacing the Suspend comman
ds with events or some other synchronization method to be compliant
going forward? If so, can someone provide an example of a best
practice. Thanks!

Yes, events are the way to go. The RTL has wrappers for Windows events
and waiting - look up SyncObjs.TEvent.
Alex Belo

Posts: 626
Registered: 10/8/06
Re: Best Practices for Updating Threads to Replace Suspend / Resume  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 19, 2016 8:31 AM   in response to: Richard Zarr in response to: Richard Zarr
Richard Zarr wrote:

We have roughly 1M lines of code

As others say your way is using events and WaitForObject(s).

To avoid massive code refactoring you can create descendant of TThread
(say, TBaseThread) and override Suspend/Resume procedures in it using
event/waitforobj paradigm. After that simply change ancestor of your
threads from TThread to TBaseThread (it's much more easier) and old
code should work fine without changes.

--
Alex
Richard Zarr

Posts: 74
Registered: 7/1/98
Re: Best Practices for Updating Threads to Replace Suspend / Resume  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 23, 2016 10:58 AM   in response to: Alex Belo in response to: Alex Belo
Alex Belo wrote:
Richard Zarr wrote:

We have roughly 1M lines of code

As others say your way is using events and WaitForObject(s).

To avoid massive code refactoring you can create descendant of TThread
(say, TBaseThread) and override Suspend/Resume procedures in it using
event/waitforobj paradigm. After that simply change ancestor of your
threads from TThread to TBaseThread (it's much more easier) and old
code should work fine without changes.

--
Alex

Clever... We've already started improving thread synchronization throughout the application. I wanted to take this time to fix possible issues so we're re-visiting all the classes since they have been collectively written over the last 5 years. Since this is a global update, we wanted to avoid dragging old paradigms into the new major revision. Fix it now or pay later is what we're thinking!
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02