On 08 Feb 2008 10:23:23 GMT andrew@cucumber.demon.co.uk (Andrew Gabriel) wrote:
> To roll your own recursive mutex, you will need to use a condition
> variable, not a plain mutex at the lower level.

what would a cv accomplish? the OP's recursive mutex class seems ok,
overflow problems excepted.

-frank

On Feb 7, 6:47*pm, Frank Cusack <fcus...@fcusack.com> wrote:
> On Thu, 7 Feb 2008 18:28:26 -0800 (PST) Cheng <cheng.still...@gmail.com> wrote:
>
> here, the mutex is "locked" recursively if the thread requesting a
> new lock is the thread that already holds the lock. *fine. *but
> if the thread requesting the lock is DIFFERENT than the thread that
> holds the lock, we continue on ...
>
> > * * int retVal = pthread_mutex_lock(&m_mutex);
>
> to here, and this will fail. *which is the correct action.
>
> the reason it works on Linux is that the mutex is never contended,
> due to thread scheduling differences.
>
Do you mean in Solaris the pthread_mutex_lock function does not block
like it does in Linux? Do you have reference and solution for this
one? Should I just add a while loop like:

while (pthread_mutex_trylock(&mutex))
{ sleep xxx;}
unlock();

in front of the pthread_mutex_lock function call? Thanks.

> BTW, the class seems pointless since pthreads provides recursive
> mutexes natively. *also, the class is buggy since it doesn't test for
> overflow of m_state.m_lockCount (i assume m_state is a struct and
> m_lockCount is an integral type and not an object which will throw an
> exception on overflow).
>
> -frank- Hide quoted text -
>
> - Show quoted text -

Cheng wrote:
> On Feb 7, 6:47 pm, Frank Cusack <fcus...@fcusack.com> wrote:
>> On Thu, 7 Feb 2008 18:28:26 -0800 (PST) Cheng <cheng.still...@gmail.com> wrote:
>>
>> here, the mutex is "locked" recursively if the thread requesting a
>> new lock is the thread that already holds the lock. fine. but
>> if the thread requesting the lock is DIFFERENT than the thread that
>> holds the lock, we continue on ...
>>
>>> int retVal = pthread_mutex_lock(&m_mutex);
>> to here, and this will fail. which is the correct action.
>>
>> the reason it works on Linux is that the mutex is never contended,
>> due to thread scheduling differences.
>>
> Do you mean in Solaris the pthread_mutex_lock function does not block
> like it does in Linux? Do you have reference and solution for this
> one? Should I just add a while loop like:
>
Your error appears to be cased by recursive locking. If your code does
this, you have to use a recursive mutex which isn't the default on Solaris.

--
Ian Collins.

Cheng <cheng.stillsea@gmail.com> writes:

>On Feb 7, 6:47=A0pm, Frank Cusack <fcus...@fcusack.com> wrote:
>> On Thu, 7 Feb 2008 18:28:26 -0800 (PST) Cheng <cheng.still...@gmail.com> w=
>rote:
>>
>> here, the mutex is "locked" recursively if the thread requesting a
>> new lock is the thread that already holds the lock. =A0fine. =A0but
>> if the thread requesting the lock is DIFFERENT than the thread that
>> holds the lock, we continue on ...
>>
>> > =A0 =A0 int retVal =3D pthread_mutex_lock(&m_mutex);
>>
>> to here, and this will fail. =A0which is the correct action.
>>
>> the reason it works on Linux is that the mutex is never contended,
>> due to thread scheduling differences.
>>
>Do you mean in Solaris the pthread_mutex_lock function does not block
>like it does in Linux? Do you have reference and solution for this
>one? Should I just add a while loop like:


No; perhaps he just didn't link with -lpthread so all therad
functions (in S9 and before) are noops.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

On Fri, 8 Feb 2008 10:22:39 -0800 (PST) Cheng <cheng.stillsea@gmail.com> wrote:
> On Feb 7, 6:47*pm, Frank Cusack <fcus...@fcusack.com> wrote:
>> the reason it works on Linux is that the mutex is never contended,
>> due to thread scheduling differences.
>>
> Do you mean in Solaris the pthread_mutex_lock function does not block
> like it does in Linux?

my mistake. yes, pthread_mutex_lock() will simply block.

so then, from what you've posted, i don't see what could be wrong.

-frank

On Sat, 09 Feb 2008 08:33:35 +1300 Ian Collins <ian-news@hotmail.com> wrote:
> Your error appears to be cased by recursive locking. If your code does
> this, you have to use a recursive mutex which isn't the default on Solaris.

if you look at his mutex class you'll see it never acquires the mutex
recursively.

-frank

On 08 Feb 2008 20:23:04 GMT Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
> No; perhaps he just didn't link with -lpthread so all therad
> functions (in S9 and before) are noops.

annoying. what was the rationale for including noops in libc as
opposed to letting that kind of error be detected at link time?

On Fri, 8 Feb 2008 16:41:20 -0800 (PST) Cheng <cheng.stillsea@gmail.com> wrote:
> Here it is:
>
> bool
> posixMutex::isProcessLocked() const
> {
> return (m_lockingProcessID == getThisProcessID() &
> m_state.m_lockCount != 0);
> }

yup, that's your race.

what's happening is that you are setting the m_lockingProcessID and
m_state with mutex held, but testing them without mutex held. classic.

> So what else should it check in your opinion? Thank you.

it would be more educational for you if you try to figure it out
first. between the above, and my earlier post saying what I assumed
isProcessLocked() was doing (if it were correct), you have the answer.
it's not *what else*, it's what instead.

where did you get this code? you said it was from an online source.

-frank

On Fri, 8 Feb 2008 15:26:50 -0800 (PST) Cheng <cheng.stillsea@gmail.com> wrote:
> -lpthread and -lthread are both used in linking.

BTW, you should use only one or the other. I suggest -lpthread unless
you specifically need some solaris threads functionality. I think
(not 100% sure) using both effectively only uses the first one on
your link command line.

-frank

I see what you mean. And it works after taking care of the data race
problem (by disabling the recursive lock checking). Thank you very
much!
However, two questions still remain:

1. What difference between Linux and Solaris threading mechanisms
causes this? Why the data race was not a problem in Linux?
2. Is there an easy solution to enable recursive checking (although it
is not really necessary) while avoiding data race? I have thought
about it but can't find a way to pass the mutex ownership info between
threads...

On Feb 8, 5:02*pm, Frank Cusack <fcus...@fcusack.com> wrote:
> On Fri, 8 Feb 2008 15:26:50 -0800 (PST) Cheng <cheng.still...@gmail.com> wrote:
>
> > -lpthread and -lthread are both used in linking.
>
> BTW, you should use only one or the other. *I suggest -lpthread unless
> you specifically need some solaris threads functionality. *I think
> (not 100% sure) using both effectively only uses the first one on
> your link command line.
>
> -frank