🚀 go-pugleaf

On Fri, 2 Apr 2004 12:58:24 +0200, Oliver Young wrote:

As a quick test if you don't understand why one of these functions is not
thread safe or how the first one is a thread safe (albeit pointless)
function then you need to do some research on threads:

// Note:These both assume that the standard libraries are thread safe.

// Safe function
int safeFn( char const * wibble )
{
  return strlen( wibble );
}

// Unsafe function
std::vector<char *> messagesRaisedByThisThread;
int unsafeFn( char const * wibble )
{
  messagesRaisedByThisThread.push_back( wibble );
}

Neither function should cause a crash but the latter is not likely to
behave the way you'd expect judging by the name of the vector.

> There will be no colision between DLLs/Functions in different threads? 
> I'm talking about fnMyFunc & MyAppDLL variables.

A thread is not a separate program it's just a separate execution point.
This means that conceptually if you have ten threads that all execute your
example code then it's exactly as if your code executed the example ten
times.

According to the normal Windows rules for DLLs this means that the calls to
LoadLibrary() and GetProcAddress() return /the same values every time/.
Whether you choose to give each thread its own variables or share one set
of globals doesn't really matter at first glance.

When thread (a) calls fnMyFunc() it sends the CPU to memory address
0x1234567 for its next instruction. When thread (b) calls fnMyFunc() it
sends to the CPU to /the exact same address/. This means that as given in
your example fnMyFunc() has no way of knowing which thread it is being
called by. This may or may not be a problem depending on what the function
does.

*In general you should assume that any function not explicitly documented
as thread safe is not thread safe*

*Functions that don't take arguments are particularly suspicious since
there is no way AFAIK that they can determine what thread called them*.

It is perfectly safe to have all the threads accessing the same copies of
MyAppDLL and fnMyFunc since they all have the same value.

Where it might become inadvisable is when each thread is responsible for
signing on and off the DLL. The problem then is how each thread is
maintaining the DLL load state and what if anything it does to the global
variables when it signs off the DLL. Your example is perfectly thread safe
even in this scenario as long as when you call FreeLibrary() you don't set
the variables back to NULL.

Oh, a further comment on my quick question. If you were to change the name
of the vector to 'messagesRaisedByAllThreads' then the function becomes
thread safe :)
-- 
Andrue Cope
[Bicester UK]