Re: first sight

From: terekhov (terekhov_at_[hidden])
Date: 2002-01-17 09:59:06

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
[...]
> > > > The right answer is awaiting you here:
> > > >
> > > > http://groups.yahoo.com/group/boost/message/22881
> > > >
> > > > one more hint: it will throw AND "protect" but it won't be
> > > > a "mutex", in the sense of "pthread_mutex_t" class objects.
> > >
> > > This one just looks like another of your mysterious links to 
me. I
> > can't
> > > understand what I read there, and the comment above is a bit
> > too "hint-y"
> > > for me to understand.
> >
> > pthread_mutex_timedlock() Rationale:
> 
> <snip>
> 
> Sorry, I read it, but what do the properties of timedlock() have to 
do with
> cancellation?
> 
> >  Perhaps you just contact Butenhof if you still
> >  have any more "why" question wrt mutex locking
> >  and cancelation.
> 
> We're definitely not at that stage yet. I'm just trying to figure 
out what
> /you're/ driving at.

Below is the device for mutual exclusion which is a
cancelation point (without proper cleanup), but which 
is NOT A PTHREAD MUTEX. The device below is called 
BIN.SEMAPHORE. In POSIX we already have it and 
sem_wait/sem_timedwait IS a mandatory cancelation 
point.

http://cvs.sourceforge.net/cgi-
bin/viewcvs.cgi/boost/boost/libs/thread/src/mutex.cpp?rev=1.7&content-
type=text/vnd.viewcvs-markup

void timed_mutex::do_lock()
{
    int res = 0;
    res = pthread_mutex_lock(&m_mutex);
    assert(res == 0);

    while (m_locked)
    {
        res = pthread_cond_wait(&m_condition, &m_mutex);
        assert(res == 0);
    }

    assert(!m_locked);
    m_locked = true;

    res = pthread_mutex_unlock(&m_mutex);
    assert(res == 0);
}

void timed_mutex::do_unlock()
{
    int res = 0;
    res = pthread_mutex_lock(&m_mutex);
    assert(res == 0);

    assert(m_locked);
    m_locked = false;

    res = pthread_cond_signal(&m_condition);
    assert(res == 0);

    res = pthread_mutex_unlock(&m_mutex);
    assert(res == 0);
}

The problem is that this device is:

a) SLOW;
b) Does not support mutex priority protocols;
c) Can not be used together with condition
   variables to build robust synchronization
   protocols.

In PTHREADS, we have just two simple devices:

1) FOR LOCKING: mutexes (not a cancel.point)
2) FOR WAITING: condition variables (cancel.point)

Semaphores are mixture of both concepts.
They ARE BAD.

Note that this is all clearly stated in PWPT 
and/or POSIX standard.

regards,
alexander.