«

Hi all,

i'm the same Nehil who was developing a conservative garbage collector
for C and was using Mark and Sweep algorithm.

I'm now aiming to extend it for multithreaded environment. Plz note
that i'm not making the garbage collector multithreaded but enhancing
the features so that it can also work for multithreaded programs.

can u please tell me some points which i should consider while
enhancing the garbage collector.

one more query i want to ask is " IS MALLOC THREAD_SAFE or NOT ? "
let say in a user program there are two threads A and B. now A calls
malloc and inside malloc it came to know about a free block which can
fulfill the requested bytes of memory. just then B calls malloc and
came to know the same block.
how malloc handels this situation cause either A or B will have the
false information about the free block. does malloc handel such
situations?
can u please tell some other situations.

Thanks.

Nehil wrote:
> Hi all,
>
> i'm the same Nehil who was developing a conservative garbage collector
> for C and was using Mark and Sweep algorithm.
>
> I'm now aiming to extend it for multithreaded environment. Plz note
> that i'm not making the garbage collector multithreaded but enhancing
> the features so that it can also work for multithreaded programs.
>
> can u please tell me some points which i should consider while
> enhancing the garbage collector.
>
> one more query i want to ask is " IS MALLOC THREAD_SAFE or NOT ? "
> let say in a user program there are two threads A and B. now A calls
> malloc and inside malloc it came to know about a free block which can
> fulfill the requested bytes of memory. just then B calls malloc and
> came to know the same block.
> how malloc handels this situation cause either A or B will have the
> false information about the free block. does malloc handel such
> situations?
> can u please tell some other situations.
>
> Thanks.
>
Some implementations are thread safe, others not.
The best way would be to build your own semaphore
handling stuff, and make it thread safe yourself.

In some operating systems like windows, you can call APIs that are
documented as thread safe.

Nehil wrote:

>
> one more query i want to ask is " IS MALLOC THREAD_SAFE or NOT ? "

The answer lies in your system's documentation.

--
Ian Collins.

Nehil wrote:

> Hi all,
>
> i'm the same Nehil who was developing a conservative garbage collector
> for C and was using Mark and Sweep algorithm.
>
> I'm now aiming to extend it for multithreaded environment. Plz note
> that i'm not making the garbage collector multithreaded but enhancing
> the features so that it can also work for multithreaded programs.
>
> can u please tell me some points which i should consider while
> enhancing the garbage collector.
>
> one more query i want to ask is " IS MALLOC THREAD_SAFE or NOT ? "

C doesn't have threads, so malloc is automatically thread-safe.

If your /implementation/ has threads, then I earnestly hope it documents
whether it's malloc (and umpty-seven other library functions) are
thread-safe or not. But, apart from my empty answer above, you'll
have to appeal to each implementation.

Maybe you can stick with whatever POSIX says.

--
Far-Fetched Hedgehog
Meaning precedes definition.

Chris Dollin wrote:

> C doesn't have threads, so malloc is automatically thread-safe.

C has this to say about reentrancy,
"The functions in the standard library are not
guaranteed to be reentrant and may modify objects with
static storage duration."

A quick look at:

http://www.google.com/search?hl=en&i...+thread+safety

suggests that there is a connection between reentrancy
and thread safety, So I would say that malloc is not thread safe.

--
pete

On Jul 21, 6:44 pm, pete <pfil...@mindspring.com> wrote:
> Chris Dollin wrote:
> > C doesn't have threads, so malloc is automatically thread-safe.
>
> C has this to say about reentrancy,
> "The functions in the standard library are not
> guaranteed to be reentrant and may modify objects with
> static storage duration."
>
> A quick look at:
>
> http://www.google.com/search?hl=en&i...ff&q=reentranc...
>
> suggests that there is a connection between reentrancy
> and thread safety, So I would say that malloc is not thread safe.
>
> --
> pete

Thanks all, for your answers.

So malloc is NOT thread safe. But can i know some conditions which i
should consider to make my own function thread safe.
i've developd my own memory allocator and now want to make it safe for
multithreaded programs.
can i get the key points to be considered.
Thanks.

Nehil wrote:
>
> On Jul 21, 6:44 pm, pete <pfil...@mindspring.com> wrote:
> > Chris Dollin wrote:
> > > C doesn't have threads, so malloc is automatically thread-safe.
> >
> > C has this to say about reentrancy,
> > "The functions in the standard library are not
> > guaranteed to be reentrant and may modify objects with
> > static storage duration."
> >
> > A quick look at:
> >
> > http://www.google.com/search?hl=en&i...ff&q=reentranc...
> >
> > suggests that there is a connection between reentrancy
> > and thread safety, So I would say that malloc is not thread safe.
> >
> > --
> > pete
>
> Thanks all, for your answers.
>
> So malloc is NOT thread safe. But can i know some conditions which i
> should consider to make my own function thread safe.
> i've developd my own memory allocator and now want to make it safe for
> multithreaded programs.
> can i get the key points to be considered.
> Thanks.

Now you're really going to have to find a newsgroup
that deals with threads.
This one doesn't.
Threads may or may not be part of POSIX, but they're not part of C.

--
pete

Nehil wrote:
> On Jul 21, 6:44 pm, pete <pfil...@mindspring.com> wrote:
>> Chris Dollin wrote:
>>> C doesn't have threads, so malloc is automatically thread-safe.
>> C has this to say about reentrancy,
>> "The functions in the standard library are not
>> guaranteed to be reentrant and may modify objects with
>> static storage duration."
>>
>> A quick look at:
>>
>> http://www.google.com/search?hl=en&i...ff&q=reentranc...
>>
>> suggests that there is a connection between reentrancy
>> and thread safety, So I would say that malloc is not thread safe.
>>
>> --
>> pete
>
> Thanks all, for your answers.
>
> So malloc is NOT thread safe. But can i know some conditions which i
> should consider to make my own function thread safe.

Just because the C standard makes no mention of threads, that doesn't
stop implementations from using them. As I said before, read your
system's documentation, this is more of a platform specific question,
than a C one.

--
Ian Collins.

"Nehil" <> wrote in message
news: ups.com...
> Hi all,
>

[...]

You can't count on malloc being thread-safe unless the documentation for the
platform explicitly states otherwise. There are ways to create scaleable
memory allocators that can handle any number of threads, but that's another
issue:

http://softwarecommunity.intel.com/i.../30235584.aspx

In article < om>,
Nehil <> wrote:

>So malloc is NOT thread safe.

Any implementation that provides threads is likely to to provide a
thread-safe malloc(), since it would be unusable otherwise.

>But can i know some conditions which i
>should consider to make my own function thread safe.
>i've developd my own memory allocator and now want to make it safe for
>multithreaded programs.

This is difficult: you will need to write appropriate code for each
implementation.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.