🚀 go-pugleaf

Remy Lebeau (TeamB) wrote:

>"Jonathan Starr" <starr@belsoft.com> wrote in message
>news:3f7b0c4e$1@newsgroups.borland.com...
>
>  
>
>>PS What is happening is that the low-pri thread *appears* to
>>begin executing at a random point while the high-pri thread
>>is busy again.
>>    
>>
>
>That should not be an issue, though.  Threads do not have any concept of
>their timings.  A thread shouldn't care about such things. 
>
In this case it does matter, since the threads are intimately connected 
by shared data.

> If the real
>issue is that you have a low-pri thread that is not resuming when you need
>it to, then you should consider tweaking the thread priorities differently.
>
Can't.  The hi-pri is the UI, and if I make the other one higher, the UI 
events get lost.  Is there
any way to avoid this?

>Alternatively, when the hi-pri thread resumes the lo-pri thread, the hi-pri
>thread could then call Sleep() to allow the lo-pri thread the oppurtunity to
>actually start right away (assuming you don't have other threads running).
>
I tried Sleep ( ) and it seems to have fixed things, thanks very 
much!!!  I don't have the Windows
API docs - can you tell me what its argument means (I just used 1)?

>>A thread may acquire a TCriticalSection a lock multiple times
>>before releasing it.  The lock maintains a counter internally.
>>    
>>
>
>Correct.
>
>  
>
>>I had thought that if a thread acquired such a lock several times
>>and released it once, it still held it - another thread would block
>>trying to acquire it until it was released as many times as acquired.
>>    
>>
>
>Correct.
>
>  
>
>>But I am seeing a case in which a single release seems to
>>allow another thread to acquire the lock.
>>    
>>
>
>Please show your actual code.
>  
>
Impractical.  I could spend days trying to strip it down to a reasonable 
case.  I may check over
my data and see if I am not seeing what I thought I was.

Thanks for the help.