Class

[Chris]

I got a doubt in the following issue...

let said i wrote a dll by exporting a class, so when the external program create a new instances of this class and call a function let said StartCount which intenally will create a thread to perform the looping. This is running fine, but when within the same application I create another new instance of this class follow by calling the same function StartCount without destroy the previous class.

So, my question is will my dll go crazy of the looping thread. which eventually will cause the variable being over written by two running thread?

Or, i need to do my internal synchronization? or it is better to develop a COM dll rather than a normal WIN32 dll.

I know the above problem does not occur when the StartCount function is being call by two seperate program simultanoiusly.

regards,
Chris.C

[CornedBee]

That depends on what kind of variable you write to.
If it is a stack variable, it is managed on a per-thread basis: there is no problem running several of them at the same time.
If it is a global variable, you would write to the same. They are managed on a per-process basis.

There are two basic solutions:
a) before creating the thread you allocate a block of memory where you store the counter. Then you pass the address of this block in the PVOID parameter of the thread's main function. This means you have one block of memory for every thread.
b) Refer to a thread local block via a global variable using thread local storage. There is a group of functions to do this, they all start with Tls.

The first one is easier. Thread local storage is a rather advanced topic.

[Chris]

Thx CornedBee, em.. i think i might look into the tls as I come acroos that before. and let me explain more about what i intend to do...

I have wrote a WIN32 DLL which will decode the GIF image file and playback frame by frame on the created window (playback window) with a 2 export function:
PlayGIF
StopGIF

But, each time the PlayGIF is call, there will create a thread to start decode the GIF image file and load each frame into memory DC till all the frame is loaded, then it start playback the image by using BitBlt within the WM_PAINT event by the frame index control by the thread together with InvalidateRect API.

Because, all the memory DC is declare a global variable under the DLL. If i move to tls, how much work I need to do or may be can give me some guideline

[CornedBee]

I have never used that before, I just know that it exists. (That's always the hardest thing in WinAPI).

Here's what I learned in my book:
The first thing you have to do is to call TlsAlloc. This will return an index that you need to store as a global variable. It's some kind of "pointer" to the memory you reserved. When there is no storage available, TlsAlloc returns TLS_OUT_OF_INDEXES.
When you're finshed, call TlsFree and pass the index.

To get and set the values, you use TlsGetValue and TlsSetValue. These functions want the index and a PVOID argument. This PVOID can be anything: any LONG or DWORD value (anything that takes 4 bytes) or a pointer to a memory block on the heap.

Win9x gives you exactly 64 TLS blocks, so be careful. Remember, your not the only person on earth, and if your DLL grabs 5 TLS blocks without good reason, and another DLL grabs another 5 and ..., then soon the app will be out of TLS.
Win2k and WinXP give you more than 1000 blocks.

There is also static thread local memory, global or static variables that are declared with
__declspec(thread)
.
DLLs that use these variables can't be used with LoadLibrary, so they have a disadvantage.

Blocks that come from TlsAlloc are always initialized with 0.