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: Jonas Maebe <email@hidden>
- Date: Mon, 20 Aug 2007 17:52:29 +0200
On 20 Aug 2007, at 17:30, Cem Karan wrote:
As it stands, I have used a similar method to write when I locked a
lock, and when I released it (all wrapped in macros). I found that
the running behavior between the debug version and the release
version never quite matched. By using long running statistical
testing (fuzzing) in my unit tests, I managed to get enough
information that I squashed most (all?) of my bugs, but what I
really want is a way of probing the state of locks in a way
guaranteed to not modify the running behavior of the threads.
In this sense, computers are like quantum states (except with
external probes on the busses or so): observing means modifying. But
it doesn't really matter that much, see below.
The only way for that to happen is for GDB to pause all threads at
the same time, and then to probe the locks individually, which,
when you really get down and dirty, is impossible.
Not only that, it would still not particularly help you. The
scheduler could still reschedule your threads in any order it wants.
How your threads are scheduled can change with any release of the OS,
with a different number of cpus, with a different input, or with a
change of the load of the machine (which subsequently makes it
dependent on the time of the day, e.g. cron, some dns lookup which
activates lookupd etc).
The "freezing the state of the program in release and looking and
then continuing like nothing happens" is merely one of the cases you
can test (and may even differ between different tries), and exactly
the same conditions will probably happen during one of the fuzzing
tests (which you need to run anyway) if you run enough of then. There
is no single "release behaviour" you can test.
Jonas
_______________________________________________
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