11.01.2017 20:59, Alex Peshkoff wrote:
> On 01/11/17 20:36, Vlad Khorsun wrote:
...
>>> I.e. slowdown is obviously present but it's too far from being irresponsive.
>> Thanks. Sad you can't reproduce it.
>
> I remember that long ago linux had some problems with pthread_yield()
> but already do not remember details, something like it did not cause
> threads rescheduling. That definitely violated posix requirements:
> pthread_yield() causes the calling thread to relinquish the CPU, the
> thread is placed at the _end_ of the run queue for its static priority
> and another thread is scheduled to run.
>
> I wonder - did you reproduce it on classic or superclassic?
Both. Debug and Release. Win7
>> I do it easily. AST thread is blocked at
>> Database::Sync::lock on syncMutex.enter() despite of a lot of checkouts in
>> worker
>> thread.
>
> Hmm... From posix POV that's a bug but certainly windows calls may have
> different rules. May be it makes sense to increase thread's priority
> when it's going to deliver AST?
I did it in AstContextHolder - not helps. I see blocked thread with
highest priority...
I plan to try to change syncMutex by Event or Mutex (currently it is Critical
Section)
and see if it helps
>> Interesting is that debugger intrusion (just a breakpoint on THREAD_YIELD()
>> at JRD_reschedule()) often helps AST thread to got control and unblock...
>
> Not too strange.
> Debugger certainly can in some way affect thread scheduling.
Sure.
Regards,
Vlad
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
