Functions that "Block" or "Blocking Threads"

[Cliff Nichols]

Is there a list of functions that "Block" (or sometimes referred to as "Blocking Threads") ???

A situation I have and have been struggling with (and not knowing it) is that redoing a long running project of mine (working with serial port devices, stepper motors etc.) that I need to make things faster. (Much faster than the serial port "General Rule of Thumb - Do not expect responses less than every 100ms")

No this old rule of thumb could be badly held because it came from my VB days and not knowing any better so I set off to see if reliably things can be done faster (since may companies claim "Real time" sort of things with serial ports and etc.)

Anyways, a problem I have been chasing is that so called "Randomly" the program just stops. (and I mean STOPS, no errors, no events, no messages, no nada) and I figured this out by logging every function and each logg over and over stops within a couple of functions (but not the same function every time)

The common link is it is always at the point of a sleep (PB, Or API) that my next line does not logg, and the program is halted. So I have to ask if the docs are incomplete? or am I missing something? or if Sleep is a blocking call?

I am working on coming up with a demo of my problem, but hoping someone can point me at how to know something is a "Blocking function" and if it is, then how do you unblock it???

[Chris Boss]

This may not be what many want to hear, but IMO the improper use of the SLEEP command can have disastrous results in apps with multiple threads.

You have to understand that the operating system is already breaking up the CPU into time slices for each and every process/thread running.

The time slice is quite small in amount of time, otherwise programs would not appear to be running simultaneously.

Now if you introduce a call to SLEEP in every iteration of a thread and the time you define in the SLEEP call is greater than the time slice defined by the operating system for each thread, then strange results can occur.

Imagine four or five jugglers passing balls around to each other in a fast rotation. Each juggler holds a couple balls for only a split second.

Now imagine an outside party is telling individual jugglers "stop" what you are doing now and go to sleep for 1 second. Can you imagine the problems created.

It is similiar to using SLEEP in threads.

Not that you shouldn't use it, but if you have multiple threads running and you are sleeping in each threads iteration (threads usually have code that runs in a loop) and then you take into consideration that the opertaing system is automatically switching between threads very quickly, then timing problems can result.

So how does one do it correctly ?

One good rule is to use as few threads as possible.

Second, use SLEEP carefully. For example, instead of calling sleep in every iteration in the thread function, use a counter and every so many iterations call sleep.

Be very carefull when using multiple threads and calling sleep in all of them. This can create all sorts of timing problems.

If possible use timers, instead of threads. Timer don't have this same problem.

Another possiblity is to use one thread as a key thread and have it use precission timers to track how fast it is running and at specific intervals call SendMessage to generate your own WM_TIMER events for the primary thread (the apps main thread). In the WM_TIMER message execute code which needs to be run at intervals. SendMessage forces a context switch to the primary thread. This way you only need one thread to track timing and all other code is executed in the primary thread.

It should be pointed out that SLEEP is not a method for controlling exact timing. For example you can't just use SLEEP 50 in a thread and assume the code will run at 20 intervals per second (50 ms is 1/20 of a second).

It is best to use a SLEEP interval which is less than the normal time slice defined by the operating system. I don't remember off hand what the time slice is normally, but it is quite small.

[Michael Mattias]

All intrinsic PB statements or functions, or calls to procedures (internal or external) "block" in the sense they do not return until execution has completed.

Some intrinsic statements may take a long time to complete, eg., TCP OPEN, and called procedures can do just about anything before returning, but AFAIK the only function which does anything asynchronously is the SHELL function, and even that isn't 'really' asynchronous, since it does not return until the attempt to launch has been completed.

BTW, if you are using multi-threading correctly, you should never need a SLEEP statement.

MCM

[Dave Biggs]

..(and I mean STOPS, no errors, no events, no messages, no nada) and I figured this out by logging every function and each logg over and over stops within a couple of functions (but not the same function every time)

The common link is it is always at the point of a sleep (PB, Or API) that my next line does not logg, and the program is halted.

When your program 'Stops' does it exit? Or does it just stop responding - Image Name still shown in Task Manager Processes display?

[Michael Mattias]

Anyways, a problem I have been chasing is that so called "Randomly" the program just stops

Programs do not stop. They terminate on a protection fault, they enter an endless loop, or they get into a state where they are waiting on something to happen.

Since your program is multi-threaded, it is also possible you entered a deadlocked state, where A is waiting on B... who is waiting on A. This would help explain the "sometimes" nature of your problem. (BTW, this will not be fun to find.)

MCM

[Cliff Nichols]

multi-threaded, it is also possible you entered a deadlocked state,

Is this the case if its my code in a Dll and 1 thread? (Or does that count as 2 threads, being my main, and 1 purposely made thread)?

I aggree it looks like a deadlock state, but I have to walk through carefully in debugger to be sure its not some infinite loop. (but if it were then I would think I would quickly run out of memory and crash out???))

Can Suspending a thread and resuming multiple times, or Suspending and calling a sleep while its suspended cause similar "Hard-to-track" bugs in my code????

[Michael Mattias]

Is this the case if its my code in a Dll and 1 thread? (Or does that count as 2 threads, being my main, and 1 purposely made thread)?

That a procedure is loaded from a DLL or the primary EXE is totally and absolutely immaterial.

All processes (one process = one instance of EXE) have a primary thread. Threads created the THREAD CREATE statement are threads 2-n of the process.

I aggree it looks like a deadlock state, but I have to walk through carefully in debugger to be sure its not some infinite loop. (but if it were then I would think I would quickly run out of memory and crash out???))

Infinite loops don't necessarily use any additional memory:

DO:  Z = 4: LOOP UNTIL  Z= 5

Can Suspending a thread and resuming multiple times, or Suspending and calling a sleep while its suspended cause similar "Hard-to-track" bugs in my code????

Yes, yes and yes.

Remember, THREAD SUSPEND and THREAD RESUME do not suspend or resume directly; they increase or decrease a suspend count. When the suspend count is zero, the thread executes; when that suspend count is greater than zero,it don't. Any possibility in your program that you have mismatched SUSPEND and RESUME statements on the same thread handle? Well, there's your "stop."

MCM