making a threadsafe localtime

[nik_cain]

hi,

Apparently MinGW hasn't got localtime_r, and I was concerned about the non thread safeness of using localtime.

I've added localtime_r to my code with the following;

#ifdef Win32
inline struct tm* localtime_r (const time_t *clock, struct tm *result) { 
	if (!clock || !result) return NULL;
	memcpy(result,localtime(clock),sizeof(*result)); 
	return result; 
}
#endif

Is that actually safe, or is it merely minimising potential problems?

nik

[Darka]

that's not thread safe at all, you need some kind of synchronisation object to protect it.

regards,

[nik_cain]

I thought as much...

I think I'd prefer writing a thread safe localtime function than just putting a mutex lock around the function above - this seems like reinventing the wheel though. Does anyone know of some localtime_r source for windows?

nik

[usman999_1]

that's not thread safe at all, you need some kind of synchronisation object to protect it.

regards,

What is not thread-safe???? localtime ???? Not even from the MultiThreaded version of CRT?????
Regards,
Usman.

[usman999_1]

I thought as much...

I think I'd prefer writing a thread safe localtime function than just putting a mutex lock around the function above - this seems like reinventing the wheel though. Does anyone know of some localtime_r source for windows?

nik

Well, you are not using any member var as far as i see, and also memcpy (you need to use MT CRT) is threadsafe. The only remaining function is localtime (i guess it comes from CRT) and from MT CRT i suppose its implemented in a Thread-safe way. If all of these conditions are true, you dont need to syn the call to your local version of localtime_r.
Hope this helps,
Regards,
Usman.

[Darka]

memcpy is not threadsafe

[Darka]

neither is localtime, just because you are using the MT version of the CRT does not mean everything is threadsafe.

[Darka]

actually, let me explain a little more.

memcpy is only threadsafe when the source and destination addresses are only accessible from a single thread, if they are accessible from other threads, then it is not thread safe.

[usman999_1]

actually, let me explain a little more.

memcpy is only threadsafe when the source and destination addresses are only accessible from a single thread, if they are accessible from other threads, then it is not thread safe.

How else can you make memcpy thread-safe. Is it possible for *any* function to know if the pointer passed into as in-param is also held by another thread????? And if thats the case then any thread-safe is not threadsafe according to you. How do u define a function to be Threadsafe then???? if you think memcpy is not.
Usman.

[Darka]

Hi Usman,

You are missing the point, the memcpy() function is threadsafe in that it can be used from many threads at the same time without any problems. However, the pointers you pass to memcpy() also need to be threadsafe, else you could end up with this...

Thread 1 enters memcpy( ) and is suspended by the OS, just before the actual data is copied to the passed in pointer.

Thread 2 deletes the object pointed to by one of the parametes that Thread 1 passed to memcpy() and is then suspended.

Thread 1 wakes up and continues copying the data to the deleted location.

To make a function threadsafe, you need to ensure the parameters passed into it are safe as well as the function itself.

[Darka]

Also...

Is it possible for *any* function to know if the pointer passed into as in-param is also held by another thread?????

no, it is up to the developer to know if the parameters being passed to the function are protected.

[usman999_1]

Hi Usman,

You are missing the point, the memcpy() function is threadsafe in that it can be used from many threads at the same time without any problems. However, the pointers you pass to memcpy() also need to be threadsafe, else you could end up with this...

Thread 1 enters memcpy( ) and is suspended by the OS, just before the actual data is copied to the passed in pointer.

Thread 2 deletes the object pointed to by one of the parametes that Thread 1 passed to memcpy() and is then suspended.

Thread 1 wakes up and continues copying the data to the deleted location.

To make a function threadsafe, you need to ensure the parameters passed into it are safe as well as the function itself.

Then is it possible to write a Thread Safe function???? Even if there is a syn object inside memcpy so only one thread enters and excecutes the code the condition you mentioned can still occur. So then we dont have any Thread Safe function in CRT??? There are also bad ways of doing things, bypass the right procedure, and that situation you mentioned is one of them, the problem of the programmer not of the function. Secondly that post
http://groups-beta.google.com/group/...cb818ecb0bc731
seems to say that localtime is also Thread safe, as the return sturct is per thread not per system or process.
Regards,
Usman.

[Darka]

Hi Usman,

Then is it possible to write a Thread Safe function????

yes, so long as you protect any shared part of that function (including the parameters passed into it) if they are shared accross multiple threads.

Even if there is a syn object inside memcpy so only one thread enters and excecutes the code the condition you mentioned can still occur.

correct, the sync object should be to protect the parameters to the localtime_r function, not within the actual memcpy call.

regards,

[nik_cain]

so... going back to my original question - if anyone knows a threadsafe windows implementation of localtime I can use (while not having access to localtime_r), I'd be very grateful. I can protect my call to localtime in the meantime, but it's an unneccessary potential bottleneck as far as I can see.

nik

[Darka]

you only need to protect it if the parameters you are passing to it are accessible from more than one thread, or if the function itself is callable from multiple threads. If not, you do not need to protect them, but should then use localtime() directly.

If they need protecting then you MUST protect them and it is then not an unneccessary bottle neck.

regards,