Are functions such as strcpy thread safe?
RickL
I have a multithread application in which I need
to copy a string
to a structure member in one thread and then pass
a pointer to
the structure to the main thread where I will
retrieve the string.
Question:
Can functions such as strcpy() be used freely
within a thread or
do these operations need to be protected with a
critical section?
Thanks,
RickL
Michael B. Allen
>-----Original Message-----
>Can functions such as strcpy() be used freely
>within a thread or
>do these operations need to be protected with a
>critical section?
Strcpy is reentrant. Meaning you can have many strcpy's
going at the same time. But you cannot strcpy from/to the
same memory at the same time. It's the data you're
operating on that you need to worry about.
Mike
Kobi Ben Tzvi
> Strcpy is reentrant. Meaning you can have many strcpy's
> going at the same time. But you cannot strcpy from/to the
> same memory at the same time. It's the data you're
> operating on that you need to worry about.
Why would there be any problem accessing simultaneously "from" string ? I
don't see any reason for this.
--
Regards,
Kobi Ben Tzvi
"Michael B. Allen" <mba...@ioplex.com> wrote in message
news:043101c37a80$b7615e00$a401...@phx.gbl...
Bob Moore
>Why would there be any problem accessing simultaneously "from" string ? I
>don't see any reason for this.
Simultaneous reads are OK, but how do you cope with a thread which is
pre-empted halfway through a write, then you do a read from another
thread ? If the operation you're working with isn't guaranteed to be
atomic, then you'll need a critical section to prevent this situation
arising.
--
Bob Moore [WinSDK MVP]
http://www.mooremvp.freeserve.co.uk/
(this is a non-commercial site and does not accept advertising)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do not reply via email unless specifically requested to do so.
Unsolicited email is NOT welcome and will go unanswered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kobi Ben Tzvi
> Simultaneous reads are OK, but how do you cope with a thread which is
> pre-empted halfway through a write, then you do a read from another
> thread ? If the operation you're working with isn't guaranteed to be
> atomic, then you'll need a critical section to prevent this situation
> arising.
I meant simultaneous reads of source string.
--
Regards,
Kobi Ben Tzvi
"Bob Moore" <bo...@mvps.org> wrote in message
news:oqs8mv0lfc0oirmkr...@4ax.com...
Norm Dresner
"Kobi Ben Tzvi" <tsum...@hotmail.comREMOVETHIS> wrote in message
news:ef5hhlse...@TK2MSFTNGP11.phx.gbl...
> Bob,
>
> > Simultaneous reads are OK, but how do you cope with a thread which is
> > pre-empted halfway through a write, then you do a read from another
> > thread ? If the operation you're working with isn't guaranteed to be
> > atomic, then you'll need a critical section to prevent this situation
> > arising.
>
> I meant simultaneous reads of source string.
>
> --
> Regards,
> Kobi Ben Tzvi
>
And if he didn't mean that what might be the source string in several
threads might be modified in yet another, he should have.
Norm
Joseph M. Newcomer
this is dangerous. Much better to allocate a block of storage (either a general "new" or
your own sub-allocator), copy the string into it, pass it to the recipient, and let the
recipient release it (either delete or your own deallocation back to your pool of
buffers). This means that there is never more than one thread, ever, using the storage.
You do not protect the function; you protect the area it is copying into. And again, only
if there really is concurrent access possible. strcpy is reentrant, meaning that there is
no reason to restrict the threads to doing only one strcpy at a time; but you must make
sure the buffer is either unique to the thread during the time of copy, or IT (not the
strcpy function) is protected against concurrent access.
If you guarantee that the other thread cannot possibly see the string until it has been
copied, it doesn't matter. strcpy can be used concurrently by many threads to copy into
disjoint string buffers. But if there is any possibility of concurrent access, you have to
provide explicit synchronization yourself.
You might want to read my essays on multithreading and on producer/consumer structures
using semaphores on my MVP Tips site.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer
is local to the thread, this is a given. If the source string is global, you have to lock
it before copying from it to make sure the source doesn't change while you are copying.
joe
On Sun, 14 Sep 2003 17:06:20 +0300, "Kobi Ben Tzvi" <tsum...@hotmail.comREMOVETHIS>
wrote:
>Bob,
>
>> Simultaneous reads are OK, but how do you cope with a thread which is
>> pre-empted halfway through a write, then you do a read from another
>> thread ? If the operation you're working with isn't guaranteed to be
>> atomic, then you'll need a critical section to prevent this situation
>> arising.
>
>I meant simultaneous reads of source string.
Joseph M. Newcomer [MVP]