Safe Threads and assoc

[Dare2]

I have an app that handles content management. From time to time it connects with the website. Most times this is quick but sometimes the job takes time, for eg uploading/downloading.

I currently make the user twiddle thumbs as this happens, but want to make the process a background task. Sometimes the task returns info in a string in memory.

I see 2 possible solutions:

• A: Open a new (hidden) window

Run that, then write strings to file, and send a message to the main app when it is over. The main app then reads in the files at first opportunity.

• B: Use a thread.

I want to do B but I am concerned that I don't understand enough about threads in general and PB's use of threads. Would this be safe:

The thread is handed a pointer to a structure containing info with needed information, and some elements are for return values.

All the elements/fields in the the structure are long integers.

Some of the elements going in will be pointers to memory blocks (used instead of strings) and some of the information collected by the threaded code will be stored in new memory blocks and the addresses stored in the structure.

Would this be safe?

When the thread ends and exits, are any thread-created memory blocks automatically freed? That is, do I need to have the thread hang around until the main app has had a chance to grab the info?


Which would be better in your opinion, window or thread?

A PS: Can file-mapping created by the parent be used by a thread? Or by the second window? (I think file mapping is the term - when a file is bulk loaded into memory and then processed from memory.)

Thanks!

[Derlidio]

You'll be fine with PB and Threads if you take some precautions when dealing shared data. PB automatically imports functions from system dlls that allows us to accomplish this. These functions are:

Code: Select all

; This goes at the top of the code.
Global CS_Object.CRITICAL_SECTION
InitializeCriticalSection_(@CS_Object) 

; This is used when you need to handle shared data:

EnterCriticalSection_(@CS_Object)
   ; Do all shared data calculations or modifications
   ; inside the Enter/Leave block. No other thread,
   ; neither the main process will be able to get
   ; ownership of the CS object until we release it...
LeaveCricitalSection_(@CS_Object)

; This goes in the end of the program...

DeleteCriticalSection_(@CS_Object)

Critical section objects assures mutual exclusion to shared data among threads within a single process. You must create one or more critical section structures (deppending on the types of shared data you have), initialize them and call the appropriated enter/leave functions before accessing the shared resources (everywhere needed). You can even assure mutual exclusion to shared data among different processes (2 different applications running at the same time) by using Mutex objects. The calls are quite the same, but with different names.

Code: Select all

Global Handle.l
Handle = CreateMutex_(*Null, 0, "MutexName")
WaitForSingleObject_(Handle)
ReleaseMutex_(Handle)
CloseHandle_(Handle)

If I can give you a piece of advide, surround "any" string variable creation/modification with a critical section block if you decide to go with threads. PB string heap is shared between the main process and its threads, so one string allocation can overlap another if they are made at the same time (I had problems with that when running multiple threads).

You can find useful info on Serialization/Sinchronization at MSDN website.

best wishes...

-PJoe

[Dare2]

You'll be fine with PB and Threads if you take some precautions ..

Hi,

Thank you for this! It was put together in an extremely helpful and educational way. I am enlightened and very appreciative. (Sometimes the information you have means nothing until someone makes it mean something, if you get my drift).

Re strings, I think I will avoid these altogether and go with memory allocations. Regardless, I will take a belt and braces approach and also wrap them in critical section blocks.

One happy chappy here!