Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #74041 > unrolled thread

is malloc free sys thread safe?

Started byasetofsymbols@gmail.com
First post2015-10-28 00:12 -0700
Last post2015-10-28 01:22 -0700
Articles 7 — 3 participants

Back to article view | Back to comp.lang.c


Contents

  is malloc free sys thread safe? asetofsymbols@gmail.com - 2015-10-28 00:12 -0700
    Re: is malloc free sys thread safe? Ian Collins <ian-news@hotmail.com> - 2015-10-28 20:22 +1300
      Re: is malloc free sys thread safe? asetofsymbols@gmail.com - 2015-10-28 00:33 -0700
        Re: is malloc free sys thread safe? Ian Collins <ian-news@hotmail.com> - 2015-10-28 21:05 +1300
          Re: is malloc free sys thread safe? James Kuyper <jameskuyper@verizon.net> - 2015-10-28 16:28 -0400
            Re: is malloc free sys thread safe? Ian Collins <ian-news@hotmail.com> - 2015-10-29 09:39 +1300
        Re: is malloc free sys thread safe? asetofsymbols@gmail.com - 2015-10-28 01:22 -0700

#74041 — is malloc free sys thread safe?

Fromasetofsymbols@gmail.com
Date2015-10-28 00:12 -0700
Subjectis malloc free sys thread safe?
Message-ID<91e0bf18-9466-4b45-8b18-4e93995ea55b@googlegroups.com>
is malloc free sys thread safe?

[toc] | [next] | [standalone]


#74042

FromIan Collins <ian-news@hotmail.com>
Date2015-10-28 20:22 +1300
Message-ID<d9bbdoFg1b3U2@mid.individual.net>
In reply to#74041
asetofsymbols@gmail.com wrote:
> is malloc free sys thread safe?

What does your documentation tell you?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]


#74043

Fromasetofsymbols@gmail.com
Date2015-10-28 00:33 -0700
Message-ID<f9617dbc-80d9-459d-80c9-5af6050512dc@googlegroups.com>
In reply to#74042
I don't know the documentation,
but in C++ conference video
I see in YouTube, there was 
one show one example 
in C++,
I imagine seen that example
 new\delete are not 
thread safe
(thread safe== only one thread
can execute malloc -free 
Or delete /new )

[toc] | [prev] | [next] | [standalone]


#74047

FromIan Collins <ian-news@hotmail.com>
Date2015-10-28 21:05 +1300
Message-ID<d9bdukFg1b3U4@mid.individual.net>
In reply to#74043
asetofsymbols@gmail.com wrote:

Where's the context?

> I don't know the documentation,

Then check your man pages or whatever passes for man pages if you are 
stuck on windows.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]


#74101

FromJames Kuyper <jameskuyper@verizon.net>
Date2015-10-28 16:28 -0400
Message-ID<n0rb1h$4mj$1@dont-email.me>
In reply to#74047
On 10/28/2015 04:05 AM, Ian Collins wrote:
> asetofsymbols@gmail.com wrote:
> 
> Where's the context?
> 
>> I don't know the documentation,
> 
> Then check your man pages or whatever passes for man pages if you are 
> stuck on windows.

Up until C2011, the standard didn't say anything about threads; the only
place to get relevant information was the documentation for the
particular implementation of the C standard library that you were using.
Starting in C2011, support for multi-threaded code was added, and
section 7.1.4 says:

"4 The functions in the standard library are not guaranteed to be
reentrant and may modify objects with static or thread storage duration.188)
5 Unless explicitly stated otherwise in the detailed descriptions that
follow, library functions shall prevent data races as follows: A library
function shall not directly or
indirectly access objects accessible by threads other than the current
thread unless the objects are accessed directly or indirectly via the
function’s arguments. A library function shall not directly or
indirectly modify objects accessible by threads other than the current
thread unless the objects are accessed directly or indirectly via the
function’s
non-const arguments.189) Implementations may share their own internal
objects between threads if the objects are not visible to users and are
protected against data races.
6 Unless otherwise specified, library functions shall perform all
operations solely within the current thread if those operations have
effects that are visible to users.190)"

The section describing the memory allocation functions contains no
additional information on this subject.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]


#74102

FromIan Collins <ian-news@hotmail.com>
Date2015-10-29 09:39 +1300
Message-ID<d9cq3vFqoecU1@mid.individual.net>
In reply to#74101
James Kuyper wrote:
> On 10/28/2015 04:05 AM, Ian Collins wrote:
>> asetofsymbols@gmail.com wrote:
>>
>> Where's the context?
>>
>>> I don't know the documentation,
>>
>> Then check your man pages or whatever passes for man pages if you are
>> stuck on windows.
>
> Up until C2011, the standard didn't say anything about threads; the only
> place to get relevant information was the documentation for the
> particular implementation of the C standard library that you were using.

Which was why I said "check your man pages".  At least in the Unix 
(like) world, there will be more than one allocator available.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]


#74052

Fromasetofsymbols@gmail.com
Date2015-10-28 01:22 -0700
Message-ID<f99eb18c-7282-4d0d-8542-6b8d71ed7e8e@googlegroups.com>
In reply to#74043
In the time 13:34 of this video
https://m.youtube.com/watch?v=lVBvHbJsg5Y
he show code using "mutex",
where already new operator
is thread safe
Can be some dead lock use
that code? 
It is 80% I'm not right in 
this doubt...

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.c


csiph-web