Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > possibly ot: thread suspension

Reply
Thread Tools

possibly ot: thread suspension

 
 
Chris Forone
Guest
Posts: n/a
 
      05-12-2008
hello group,

how does a thread suspend itself? is a volatile bool enough, that is
checked after each loop?

thanx a lot & hand, chris
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      05-12-2008
On 12 mai, 09:15, Chris Forone <(E-Mail Removed)> wrote:

> how does a thread suspend itself? is a volatile bool enough,
> that is checked after each loop?


It calls the appropriate system function, depending on the
system. You'll have to ask in a group appropriate for whatever
system you're using. (In general, though, volatile is neither
necessary nor sufficient.)

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
 
 
 
Gianni Mariani
Guest
Posts: n/a
 
      05-12-2008
Chris Forone wrote:
> hello group,
>
> how does a thread suspend itself? is a volatile bool enough, that is
> checked after each loop?


This is OT but not for long.

The standard i/f for thread "suspension" will probably be "condition
variables" IIRC.
 
Reply With Quote
 
Szabolcs Ferenczi
Guest
Posts: n/a
 
      05-12-2008
On May 12, 9:15*am, Chris Forone <(E-Mail Removed)> wrote:

> how does a thread suspend itself? is a volatile bool enough, that is
> checked after each loop?


In contrast to Java, the volatile is not introduced for the
concurrency issues in C++ and the volatile keyword has the only effect
on compiler optimisations. Once you declared a variable volatile, the
compiler will refrain from certain optimisations. That is all. In C++,
the volatile keyword does not include atomic access as it does for
simple types in Java.

Now about the suspend issue: If there are concurrent threads of
computation going on and these threads share some variables, from the
perspective of one thread, those shared variables change values non-
deterministically. Therefore, whenever a thread inspects such a
variable and expects a certain state from that variable in order to do
some further computation, it must not just check it and do something
else if it does not apply. Rather the thread of computation should
wait for that state of condition to apply. It could do busy wait on it
as well, and if it were the only thread assigned to that physical
processor, it could certainly do that. In most cases one physical
processor carries out a number of threads of computation in an
overlapping manner. So, the run-time system rather suspends the thread
that is waiting for a certain state of condition on a shared variable.

There is a background for the necessity of waiting: If the variable is
maintained exclusively by a single thread of computation and that
thread checks that variable, the check result is either false or true
but once false it will always be false and once true it will always be
true. It is because the variable can be changed by that thread only
and that thread can have a chance to change it only if it proceeds.
The situation is different in case of the shared variables: once false
it might be true in the next moment due to a concurrent operation by
an other thread of computation.

In high level language you could just state the condition and the run-
time system arranges for the suspension if necessary. If C++ were a
high level concurrent language, you could state something like this:

shared class BoundedBuffer {
std::dequeue<int> b;
public:
int get() {
when (!b.empty()) {
return b.pop_front();
}
}
...
};

Note that the `shared' declaration denotes a critical resource, which
is protected against simultaneous access. The `when' statement
specifies in what condition the computation can proceed with the
critical action. A possible suspension is arranged automatically.

In contrast, if you work with low level libraries in C++, you have to
arrange about delaying the operation yourself. In most libraries there
is a so-called condition variable for this but you have to care about
the mutual exclusion as well:

class BoundedBuffer {
std::dequeue<int> b;
pthread_cond_t empty;
pthread_cond_t full;
pthread_mutex_t guard;
public:
int get() {
int ret;
pthread_mutex_lock(&guard);
while (b.empty()) {
pthread_cond_wait(&full, &guard);
}
ret = b.pop_front();
pthread_cond_signal(&empty);
pthread_mutex_unlock(&guard);
return ret;
}
...
};

Now you have suspended the thread in case there is no element in the
buffer. The thread would normally be awaken later on by a signal sent
from a corresponding put operation indicating that the buffer has
elements to consume.

If you want to check the return values of the library operations, your
code will be even more complex.

Best Regards,
Szabolcs
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-13-2008
On May 13, 1:29 am, "Chris Thomasson" <(E-Mail Removed)> wrote:
> "Szabolcs Ferenczi" <(E-Mail Removed)> wrote in message


> news:(E-Mail Removed)...
> On May 12, 9:15 am, Chris Forone <(E-Mail Removed)> wrote:


> > how does a thread suspend itself? is a volatile bool enough,
> > that is checked after each loop?


> [...]


> > If you want to check the return values of the library operations


> You must check the return values of pthread calls. IMVHO,
> applications that fail to at least check status of pthread
> calls are crap.


I more or less agree, but... What do you do if
pthread_mutex_lock() fails? In many cases, the only possible
cause of failure will be a programming error elsewhere, or
insufficient resources. In both cases, most of the time, about
all you can reasonably do is abort with an error message.

(You definitely do have to consider the case, of course. If
pthread_mutex_lock() returns with an error, you do NOT have the
lock.)

> > your code will be even more complex.


> Why? You can wrap the raw API calls.


Generally, you should have anything at that low a level wrapped
in a class anyway.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-14-2008
On May 13, 10:10 pm, "Chris Thomasson" <(E-Mail Removed)> wrote:
> "James Kanze" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
> On May 13, 1:29 am, "Chris Thomasson" <(E-Mail Removed)> wrote:
>
>
>
> > > "Szabolcs Ferenczi" <(E-Mail Removed)> wrote in message
> > >news:(E-Mail Removed)...
> > > On May 12, 9:15 am, Chris Forone <(E-Mail Removed)> wrote:
> > > > how does a thread suspend itself? is a volatile bool enough,
> > > > that is checked after each loop?
> > > [...]
> > > > If you want to check the return values of the library operations
> > > You must check the return values of pthread calls. IMVHO,
> > > applications that fail to at least check status of pthread
> > > calls are crap.

> > I more or less agree, but... What do you do if
> > pthread_mutex_lock() fails? In many cases, the only possible
> > cause of failure will be a programming error elsewhere, or
> > insufficient resources. In both cases, most of the time, about
> > all you can reasonably do is abort with an error message.
> > (You definitely do have to consider the case, of course. If
> > pthread_mutex_lock() returns with an error, you do NOT have the
> > lock.)

>
> I tend to decorate the lock procedure with throw() and just call
> std::unexpected() when shi% hits the fan. Although, one could use
> exceptions... Which brief pseudo-code sketch do you like better:
>
> class mutex_with_exceptions {
> pthread_mutex_t m_mtx;
>
> [...];
>
> public:
> struct error {
> struct base {};
>
> struct lock {
> struct base : public error::base {};
> struct invalid : public lock::base {};
> struct priority_violation : pubilc lock::invalid {};
> struct deadlock : public lock::base {};
> struct max_recursion : public lock::base {};
>
> static void raise_status(int const status) {
> switch (status) {
> case EINVAL:
> throw priority_violation();
> case EAGAIN:
> throw max_recursion();
> case EDEADLK:
> throw deadlock();
> default:
> assert(false);
> std::unexpected();
> }
> }
> };
>
> struct unlock {
> struct base : public error::base {};
> struct not_owner : public unlock::base {};
>
> static void raise_status(int const status) {
> switch (status) {
> case EPERM:
> throw not_owner();
> default:
> assert(false);
> std::unexpected();
> }
> }
> };
> };
>
> public:
> void lock() {
> int const status = pthread_mutex_lock(&m_mtx);
> if (status) {
> error::lock::raise_status(status);
> }
> }
>
> void unlock() {
> int const status = pthread_mutex_unlock(&m_mtx);
> if (status) {
> error::unlock::raise_status(status);
> }
> }
>
> };
>
> -- or --
>
> class mutex {
> pthread_mutex_t m_mtx;
>
> [...];
>
> public:
> void lock() throw() {
> int const status = pthread_mutex_lock(&m_mtx);
> if (status) {
> assert(false);
> std::unexpected();
> }
> }
>
> void unlock() throw() {
> int const status = pthread_mutex_unlock(&m_mtx);
> if (status) {
> assert(false);
> std::unexpected();
> }
> }
>
> };
>
> ?
>
> > > > your code will be even more complex.
> > > Why? You can wrap the raw API calls.

> > Generally, you should have anything at that low a level wrapped
> > in a class anyway.

>
> Indeed!


 
Reply With Quote
 
Chris Forone
Guest
Posts: n/a
 
      05-15-2008
Chris Thomasson schrieb:
> "Chris Forone" <(E-Mail Removed)> wrote in message
> news:g08qpt$ct0$(E-Mail Removed)...
>> hello group,
>>
>> how does a thread suspend itself? is a volatile bool enough, that is
>> checked after each loop?

>
> What is the thread suspending itself for? What do you want it to wait on?

sorry for the delay,

the thread has an endless working-function that does something and after
this it sleeps for a calculatet period of time. i want suspend the
thread from another thread, BUT suspension should only occur at the end
of the endless loop (after the sleep & before the new activity).

have mingw & win32
(http://msdn.microsoft.com/en-us/libr...45(VS.85).aspx)

thanks a lot & hand, chris
 
Reply With Quote
 
Chris Forone
Guest
Posts: n/a
 
      05-15-2008
> Best Regards,
> Szabolcs


thanks a lot!!! chris
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
possibly safe usage of Thread#raise? Eric Wong Ruby 0 04-21-2011 11:26 PM
ISP account suspension virus...... steve NZ Computing 25 06-06-2005 10:57 AM
Temporary program suspension Thomas Carter C Programming 12 02-23-2005 03:56 PM
interfearance, possibly from cordless phones? is there a fix? =?Utf-8?B?R3JlZw==?= Wireless Networking 8 10-05-2004 01:42 PM
Problem with arrays or possibly HTML::Element Brett Perl 0 12-19-2003 06:13 AM



Advertisments