🚀 go-pugleaf

"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.  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.
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).


> 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.


Gambit