Re: Custom data formatter for pthread_mutex_t?
Re: Custom data formatter for pthread_mutex_t?
- Subject: Re: Custom data formatter for pthread_mutex_t?
- From: alex <email@hidden>
- Date: Fri, 17 Aug 2007 08:25:31 -0700
I'm not worried about this condition as the code is passive and is only used when the process is stopped. In my case the status stores are atomic anyway.
a
At 10:14 PM -0400 8/16/07, Kyle Sluder wrote:
>Aren't you worried that you've created a race condition, whereby a
>lock / unlock / status-report will report the wrong mutex status?
>
>--Kyle Sluder
>
>On 8/16/07, alex <email@hidden> wrote:
>> I ran into the same problem and ended up wrapping all of the pthread implementation with my own covers. They basically call straight thru to the pthread APIs but also report the lock status to a pre-allocated buffer. The intention was to cause minimal disturbance to the code and this works for me. The code is enabled with a preprocessor statement so that I can have the routines inline the call to the pthread API when I don't need to check the lock states (i.e. working release target).
>>
>> The deal is that you only look at the lock states when the process/thread is stopped-- if you try to log stuff while the code is running you will change the behavior/timing of your code.
>>
>> alex
>>
>>
>> At 4:32 PM -0400 8/16/07, Karan, Cem (Civ, ARL/CISD) wrote:
>> >Yes, this was the solution that I thought of originally, but as I
>> >mentioned before, I don't want to affect the running behavior of my
>> >program at all, if I can avoid it. Its unlikely that I can do it, but
>> >if I could write a pthread_mutex_state() function that doesn't affect
>> >the state of the mutexes, or of the pthreads library, then I could be
>> >fairly certain that my code runs the same under both debug and release
>> >states.
>> >
>> >Thanks,
>> >Cem Karan
>> >
>> >-----Original Message-----
>> >From: Alastair Houghton [mailto:email@hidden]
>> >Sent: Thursday, August 16, 2007 3:16 PM
>> >To: Karan, Cem (Civ, ARL/CISD)
>> >Cc: Xcode Users; Peter Mulholland; Dave Camp
>> >Subject: Re: Custom data formatter for pthread_mutex_t?
>> >
>> >On 15 Aug 2007, at 15:05, Cem Karan wrote:
>> >
>> >> On Tue, 14 Aug 2007 22:47:13 +0100, Peter Mulholland wrote:
>> >>
>> >>> What you're suggesting would be useful though... in a function would
>> >>> be even more useful.. like pthread_mutex_state().
>> >>
>> >> Thank you both. Peter, I agree with you that as a function, this
>> >> would be extremely useful. In a way, I'm kind of surprised that the
>> >> POSIX spec doesn't have it. Dave, you're right that I can probably
>> >> download the source and write up my own pthread_mutex_state ().
>> >
>> >You don't need the source for that:
>> >
>> > typedef enum { LOCKED = 1, UNLOCKED = 0, INVALID = -1 }
>> >mutex_state_t;
>> >
>> > mutex_state_t
>> > pthread_mutex_state (pthread_mutex_t *mutex)
>> > {
>> > int ret = pthread_mutex_trylock (mutex);
>> >
>> > if (ret == 0) {
>> > pthread_mutex_unlock (mutex);
>> > return UNLOCKED;
>> > }
>> >
>> > if (ret == EBUSY)
>> > return LOCKED;
>> >
>> > return INVALID;
>> > }
>> >
>> >Obviously it's not perfect, since it will lock and unlock the mutex to
>> >do its test (sometimes, anyway). You might be able to come up with a
>> >better solution by getting the code from Darwin, though from what I
>> >remember it's all based on Mach primitives under the covers anyway, so
>> >you'd need some way to get *their* state in order to do much better.
>> >
>> >Kind regards,
>> >
>> >Alastair.
>> >
>> >--
>> >http://alastairs-place.net
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> >Do not post admin requests to the list. They will be ignored.
>> >Xcode-users mailing list (email@hidden)
>> >Help/Unsubscribe/Update your Subscription:
>> >
>> >This email sent to email@hidden
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
> > Xcode-users mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden