Re: is malloc thread-safe??
- From: Chris Torek <nospam@xxxxxxxxx>
- Date: 28 Jul 2007 09:13:10 GMT
In article <2hkla3dtfbd0mjpo32oajnen5unlem453u@xxxxxxx>
¬a\\/b <al@xxx> wrote:
[this guy is in my kill-file but Richard Tobin, below, is not, and
I need to quote at least a little code]
char* mymalloc(int a)
{static unsigned here=0;
char *v;
if(a<0) return 0;
la:;
if(here==1)
{sleep(1); goto la;}
else
{++here;
if(here>=2)
{here=0; goto la;}
v=malloc(a);
here=0; return v;
}
}
this is thread safe?
No.
In article <f8es2n$1fr$1@xxxxxxxxxxxxxxxxxxxxxxx>
Richard Tobin <richard@xxxxxxxxxxxxxxx> wrote:
I haven't looked closely enough to see whather there are race conditions,
There are. In particular:
but in any case
(a) you would need to declare "here" to be volatile
(b) you would need to ensure that it was an atomic type (sig_atomic_t
should work)
Using "volatile sig_atomic_t" is only guaranteed against signals,
and only for simple assignments.
In practice, the code really fails on many real implementations --
those that use a load/store model in hardware, and do arithmetic
only in registers -- even when using "volatile sig_atomic_t",
because the C-level code:
++here;
translates into the machine-code sequence:
load <memaddr>, reg # where <memaddr> is the static variable "here"
add reg, 1, reg
store reg, <memaddr>
since there is no way to add a value directly to a memory location.
If two separate threads that share the variable both execute the
"load" instruction simultaneously (presumably on two separate CPUs),
then both execute the "add", then both execute the "store", the
variable will increment by 1, even though two threads have modified
it. (Even if there is only one CPU, if one thread executes the
"load" and maybe "add", but is then interrupted by the second before
it can do the "store", the second thread can load, add, and store,
and then the first thread will, upon being resumed, execute its
store.)
This race-window is quite small, which makes debugging extraordinarily
difficult. (Those who have built SMP systems are familiar with
the problem. :-) )
(c) calling sleep(1) in an allocator is likely to result in disappointing
performance, even if it allows other threads to run.
It will usually make more sense to use an implementation-dependent
locking mechanism.
Indeed. In fact, given Standard C (and even non-Standard Extended
C on some systems), an implementation-dependent locking mechanism
is in fact required on many machines. (Some C compilers have no
way to generate the machine's special atomic instruction(s), such
as the V7 SPARC "ldstub" instruction. In these cases the special
mechanisms are usually coded in C-callable assembly.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
.
- Follow-Ups:
- Re: is malloc thread-safe??
- From: ¬a\\/b
- Re: is malloc thread-safe??
- References:
- is malloc thread-safe??
- From: Nehil
- Re: is malloc thread-safe??
- From: Richard Tobin
- Re: is malloc thread-safe??
- From: ¬a\\/b
- Re: is malloc thread-safe??
- From: Richard Tobin
- is malloc thread-safe??
- Prev by Date: OT - Re: COMPILER
- Next by Date: Re: OT - Re: COMPILER
- Previous by thread: Re: is malloc thread-safe??
- Next by thread: Re: is malloc thread-safe??
- Index(es):
Relevant Pages
|
