Some unix systems will hard spin on a delay of less than 10msec. The result for a cross thread scheduling couid be that the thread communicated 'to' might start immediately and hit the lock held by the 'from' thread before it past posting the event. If the 'from' thread didn't initialize some of the shared data completely till after posting the event (on the assumption that there would be a delay) this might cause problems.
just an idea. john On Mon, Aug 22, 2011 at 1:35 AM, Brian Geffon <[email protected]> wrote: > If anyone is listening to this thread, I have narrowed the problem > down to TSContSchedule(), I can't figure out exactly why it's > happening but when the timeout is very small (either 0 or < 10ms) or > so, it caues MUTEX_TRY_LOCK_FOR to throw a segfault, if I increase the > time to 1000ms it will never happen.. I've been digging through the > code and cannot find anything that would indicate the cause. Does > anyone have ideas of where I might look? This is not happening on OS > X, it only happens on RedHat Enterprise, I'll be checking another > linux distribution soon. Thanks in advance. > > Best, > Brian > > On Tue, Aug 16, 2011 at 7:41 PM, Leif Hedstrom <[email protected]> wrote: > > On 08/16/2011 08:17 PM, Brian Geffon wrote: > >> > >> Hi, for some reason I'm getting a segfault originating in > >> UnixEThread.cc:130 from the macro expansion of MUTEX_TRY_LOCK_FOR. > >> I've been digging and I can't exactly see where the SEGFAULT is coming > >> from and I was hoping someone might have an idea of how/where to look. > >> Attached is gdb dump with variable printouts > > > > Version? > > > > -- leif > > > > >
