Re: possibly ot: thread suspension
"James Kanze" <james.kanze@gmail.com> wrote in message
news:011a1c7e-cf70-4a63-9fec-cdd20647af6d@p25g2000hsf.googlegroups.com...
On May 13, 1:29 am, "Chris Thomasson" <cris...@comcast.net> wrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
news:dd13a776-05a7-440f-9d3f-85e9be1f975b@d77g2000hsb.googlegroups.com...
On May 12, 9:15 am, Chris Forone <4...@gmx.at> 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!