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: "Karan, Cem (Civ, ARL/CISD)" <email@hidden>
- Date: Mon, 20 Aug 2007 08:14:05 -0400
- Thread-topic: Custom data formatter for pthread_mutex_t?
Apologies about coming in late, I've been out for 3 days.
Alex, I'm not sure I understand what you are doing; how are you ensuring
that the code is only called when your process is stopped? Do you mean
that your code is writing the state of the lock right before it calls a
pthread_cond_wait(), and that your threads are not affected by this
extra code, or do you mean that you've gotten GDB/Xcode to execute code
only when you hit a breakpoint? If you've got some nifty way of making
the latter happen such that there is 0 overhead while the code is
normally running, I'd love to hear it! I know that if I can sample the
state of a lock after I've hit a breakpoint, then life is good.
Hmmm.... OK, I have no experience with custom data formatters, so please
forgive my ignorance. Is it possible to write a custom formatter that
can call pthread_mutex_trylock()from within XCode/GDB's context on a
lock in the application's context? If so, then I can let my code run
until it hits a breakpoint, know that the code is stopped, and use
trylock() to test the state of the lock. This would also negate the
need for custom macros and all the other usual tricks, and it would be
portable to any pthreads code that needs to be debugged (the data
formatter can be with Xcode, not the project code)
Thanks,
Cem Karan
-----Original Message-----
From: alex [mailto:email@hidden]
Sent: Friday, August 17, 2007 11:26 AM
To: Kyle Sluder
Cc: Karan, Cem (Civ, ARL/CISD); Alastair Houghton; Xcode Users
Subject: Re: Custom data formatter for pthread_mutex_t?
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:
>> l.com
>>
>> 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