Re: [boost] Re: Threads: what I wrote...

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2000-08-08 14:45:34

Hi,

--- William Kempf <sirwillard_at_[hidden]> wrote:
> --- In boost_at_[hidden], scleary_at_j... wrote:

> > IMO, pthreads is a good example of object-oriented C.  Object = 
> data +
> > related functions -> pthread_mutex_t + pthread_mutex_init,
> > pthread_mutex_destroy, pthread_mutex_lock, ...
> 
> Agreed, but this all implies too many restrictions on the OO model.  
> The simplest example to give in this regard is the requirement that 
> the thread creation routines take a function pointer and a void 
> pointer as arguments.

I disagree with this being a restriction: This can be used to implement
whatever design we choose, including a base class with an overriden
function being started. The function pointer used is internal to the
implementation. Here is a potential implementation:

  extern "C" void* run_thread(void*);

  struct thread {
    void run() {
      if (pthread_create(&m_thread, &m_attr, run_tread ,this))
        throw "thread could not be created!";
    }
    // ...

  private:
    friend void* thread_run(void*);
    virtual int do_run() = 0;

    pthread_t      m_thread;
    pthread_attr_t m_attr;
  };

  void* run_thread(void* obj) {
    pthread_exit(static_cast<thread*>(obj)->do_run());
    return 0;
  }

With something like this, we have objects to be run and can easily
create derived functions calling whatever kind of function object we
want to call. ... and the pthreads interface is not at all visible.  

> > In fact, the related functions map so well to member functions that
> > a wrapper class can be written almost without thought (error
> > checking ommitted, but can be easily added):
> >   class mutex {
> >     private:
> >       pthread_mutex_t me;
> >       mutex(const mutex &);
> >       void operator=(const mutex &);
> >     public:
> >       mutex() { pthread_mutex_init(&me, 0); }
> >       ~mutex() { pthread_mutex_destroy(&me); }
> >       void lock() { pthread_mutex_lock(&me); }
> >       void unlock() { pthread_mutex_unlock(&me); }
> >       bool trylock() { return !pthread_mutex_trylock(&me); }
> >   };

This is the kind of interfaces I want to avoid! You can lock the mutex
without automatic release. This wrapper is clearly too thin.

> Is it possible to copy a mutex class?

This was taken care of: The copy ctor and assignment are declared to
be private and thus these objects can neither be copied nor assigned.
This is, IMO, the right semantics. Possible, there could be function to
copy attributes like there is for IOStreams ('copyfmt()') to create a
mutex with identical attributes or to safe the attributes to be
restored later but I don't think mutex can be copied.

=====
<mailto:dietmar_kuehl_at_[hidden]>
<http://www.dietmar-kuehl.de/>

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/