Re: Mutex, for static objects

----- Original Message ----- 
From: "Kevin Atkinson" <[email protected]>
To: "Gary Setter" <[email protected]>
Sent: Wednesday, October 27, 2004 10:32 AM
Subject: Re: [aspell-devel] Mutex, for static objects


> On Wed, 27 Oct 2004, Gary Setter wrote:
>
> > If you defined  USE_POSIX_MUTEX you eventually execute this
lock
> > method of Mutex:
> >
> >     void lock() {pthread_mutex_lock(&l_);}
> >
> > Kevin, are you defining USE_POSIX_MUTEX  when you build? If
so,
> > the unix version does attempt creating a mutex before main is
> > called.
> >
> > Why doesn't you code check for failure? Did you make a
version
> > that does check for failture. If so, what were the results.
>
> Because there is NO REASON FOR IT TO FAIL.  It is perfectly
legal to call
> these before main is called.  I don't know why you are having a
problem.
This seems like an odd response from someone who has programed
for awhile on several systems. Unexpected things do happen.
Anticipating errors and handling them properly is a major part of
software development.  Not checking for failure because you can't
imagine why it would fail is bad judgment. Talk to a professor or
a mentor about this.

>
> IN fact the manual states that "pthread_mutex_init always
returns 0."  The
> other ones will only fail if they are error checking mutexes,
which they
> are not.
>
> Attached in a version of lock.hpp which does check the return
value.  I
> ran it with no problem, just as I thought.
>
The code is conditionally compiled. If you used make and your
makefile defined USE_POSIX_MUTEX, then you were right and I have
my answer. Just to be kind would you please verify that
USE_POSIX_MUTEX  was defined and that the first rendition of
Mutex was compiled?

Do you know you have a valid valid in Mutex::l_ ?

> > The solution to the mutex creation on Windows problem is most
> > likely elimination of the global vars. I would be much more
> > interested in putting the effort to make that work if
elimination
> > of the globals is also your goal. Is it?
>
> NO.  As there is no reason to.
>
Except that global vars are generally a bad thing and that it is
a hang up for making the code both portable and rigerous.

> > > > PS. I asked before how to test a locking via a mutex and
> > received
> > > > no replies. I ask again. Can anyone tell me how to go
about
> > > > verifying this feature?
> > >
> > > I really am not sure what you are asking for.
> >
> > I'm asking for suggestions on how to test the mutex locks.
Have
> > you studied software verification? I'm not sure how rigorous
this
> > needs to be, but since locks are less overt then other parts
of
> > the project, it would seem to me that more care is needed to
> > determine if the feature is working right. How can I be sure
that
> > my Mutex code is working?
>
> Check the return value.  You may need to use error checking
mutexes.
>
I was thinking of a functional test. Some multithread application
where having an effective lock would make a difference.

Thanks for replying to me.
Best regards,
Gary