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: Mon, 20 Aug 2007 07:52:10 -0700
Okay, let me explain a bit better:
Each "lock" has 8 bits that is statically allocated to the lock at "compile time". Therefore every lock I create has a little "scratch pad" associated with it. This scratch pad is actually just a big memory block that I have partitioned for each lock that is created.
I wrap every pthread API with my own routine that calls straight thru to the pthread API and after that simply writes the return value of that API call into the scratch area for that lock. I used a macro to write to the scratch data so that part can be disabled in release code.
Finally the way you use this is you write a function to walk thru your scratch pad and return all the lock states- This function can only be called when the program is stopped. This takes advantage of the fact that GDB allows you to call functions directly:
(gdb) call (void)DebugPrintLockStates()
$1 = { lock states listed here }
Hope this helps,
alex
At 8:14 AM -0400 8/20/07, Karan, Cem (Civ, ARL/CISD) wrote:
>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