🚀 go-pugleaf

"Jonathan Starr" <starr@belsoft.com> wrote in message
news:3f7b0c4e$1@newsgroups.borland.com...
> I have two issues:
>
> 1. thread suspend/resume
>
> If a low-priority thread is suspended, and a high-priority thread
> Resumes the low-pri thread but the high-priority thread continues
> to run, under what cirsumstances will the low-pri thread actually
> begin to execute?

In rough terms, when there is no higher priority thread requiring
CPU resources.

In practice, it's s little more complex than that was the
scheduler (at least under NT) is able to temporarily
increase the priority of threads in some circumstances.

>
> If the high-pri thread, while continuing to run, calls a thread method of
> the low-pri thread to Synchronize, will that make any difference (the
> high-pri thread should be the UI thread, and would call the other
> thread's method just to avoid duplicate code or complicated flow control).

You're misunderstanding what Synchronize() does.  It sends a
message to the main UI thread and --- when that message is received ---
the main UI thread calls the function involved.  If Synchronize()
is called from the main UI thread, it simply calls the function
given.   If Synchronize() is called by another thread, that thread
is forced to wait until the main GUI thread has finished executing
the function.


>
> Thanks in advance.
>
> 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 is consistent.  The high priority thread (your UI thread)
is busy executing the function.  The low priority thread
resumes execution at whatever point it was suspended.

>
> 2. locking
>
> A thread may acquire a TCriticalSection a lock multiple times before
> releasing it.  The
> lock maintains a counter internally.

Not quite true.   A thread is allowed to acquire a critical section
more than once, and is guaranteed not to block if it already
holds the critical section, and attempts to lock it again.

There is no mention in the win32 documentation of any need
to release a critical section multiple times if it has been
entered multiple times.

>
> 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.  But I am seeing a case in which a single
> release seems to
> allow another thread to acquire the lock.
>

If yo uwant to do this, you may wish to consider using a semaphore
type.