------=_Part_6579_17109961.1369853027088
Content-Type: text/plain; charset=ISO-8859-1

Hi

This seams to be a very simplistic request but I think it would be nice to
have some traits to know if a function call is lock free or not.
It is not usefull for every function, but it could be for the class like
thread obviously.
Clearly launching a thread is not, but depending on the implementation
get_id could be;

I say that because in time critical thread you want to know it it is safe
to do that.
In my case i want to know if I am in the time critical thread, ... problem,
if asking for the id of the thread is not lock free I might just have break
the rule I wanted to inforce by asking if I was in this thread,

what do you think ?

NB, if this subject has already been discussed I'm really sorry for the
trouble

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_6579_17109961.1369853027088
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi<div><br></div><div>This seams to be a very simplistic request but I thin=
k it would be nice to have some traits to know if a function call is lock f=
ree or not.</div><div>It is not usefull for every function, but it could be=
 for the class like thread obviously.</div><div>Clearly launching a thread =
is not, but depending on the implementation get_id could be;</div><div><br>=
</div><div>I say that because in time critical thread you want to know it i=
t is safe to do that.</div><div>In my case i want to know if I am in the ti=
me critical thread, ... problem, if asking for the id of the thread is not =
lock free I might just have break the rule I wanted to inforce by asking if=
 I was in this thread,</div><div><br></div><div>what do you think ?</div><d=
iv><br></div><div>NB, if this subject has already been discussed I'm really=
 sorry for the trouble</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_6579_17109961.1369853027088--

.

On 5/29/13, adrien courdavault <adrien59cadri@gmail.com> wrote:
> This seams to be a very simplistic request but I think it would be
> nice to have some traits to know if a function call is lock free
> or not.  It is not usefull for every function, but it could be
> for the class like thread obviously.  Clearly launching a thread
> is not, but depending on the implementation get_id could be;
>
> I say that because in time critical thread you want to know it
> it is safe to do that.  In my case i want to know if I am in the
> time critical thread, ... problem, if asking for the id of the
> thread is not lock free I might just have break the rule I wanted
> to inforce by asking if I was in this thread, what do you think?

We might be able to provide this query definitively for a
pre-determined set of functions.  In general, though, I think we
would need to be able to answer "don't know".

Do you have a list of other functions for which you must know?
Do you need a dynamic test, i.e. on a function pointer, or can
you live with a static test, i.e. on a template argument?

--
Lawrence Crowl

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

Hi

Clearly a static info would be great if possible, that is why i said a trait
I don't have a clear list in mind, but any "status" function like
future::valid I would like to have this feature
also, It could be interesting on some containers in general or
allocators (like allocators). But this could also be done by choosing
policies (the problem could then be that some policies are not
implemented). I looked at the lockfree lib of boost recently, it is
nice but not so clear to use.

In general that could be useful for anything which depending on the
implementation should or may be lock free or not.
Also then comes the issue of lock free vs wait free ...

I don't know really what is best but I really miss a feature that
could be used to say this is ok, this is not.

Finally the problem with compile time would be for dlls.. maybe having
a way to get this compile time info at runtime would be nice, so it
would work with dll/so too.

I know this is not really clear

On 29 May 2013 21:24, Lawrence Crowl <crowl@googlers.com> wrote:
> On 5/29/13, adrien courdavault <adrien59cadri@gmail.com> wrote:
>> This seams to be a very simplistic request but I think it would be
>> nice to have some traits to know if a function call is lock free
>> or not.  It is not usefull for every function, but it could be
>> for the class like thread obviously.  Clearly launching a thread
>> is not, but depending on the implementation get_id could be;
>>
>> I say that because in time critical thread you want to know it
>> it is safe to do that.  In my case i want to know if I am in the
>> time critical thread, ... problem, if asking for the id of the
>> thread is not lock free I might just have break the rule I wanted
>> to inforce by asking if I was in this thread, what do you think?
>
> We might be able to provide this query definitively for a
> pre-determined set of functions.  In general, though, I think we
> would need to be able to answer "don't know".
>
> Do you have a list of other functions for which you must know?
> Do you need a dynamic test, i.e. on a function pointer, or can
> you live with a static test, i.e. on a template argument?
>
> --
> Lawrence Crowl
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/2iCzaKc2PRE/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On 5/29/13, adrien courdavault <adrien59cadri@gmail.com> wrote:
> Clearly a static info would be great if possible, that is why i said a
> trait
> I don't have a clear list in mind, but any "status" function like
> future::valid I would like to have this feature
> also, It could be interesting on some containers in general or
> allocators (like allocators). But this could also be done by choosing
> policies (the problem could then be that some policies are not
> implemented). I looked at the lockfree lib of boost recently, it is
> nice but not so clear to use.
>
> In general that could be useful for anything which depending on the
> implementation should or may be lock free or not.
> Also then comes the issue of lock free vs wait free ...
>
> I don't know really what is best but I really miss a feature that
> could be used to say this is ok, this is not.
>
> Finally the problem with compile time would be for dlls.. maybe having
> a way to get this compile time info at runtime would be nice, so it
> would work with dll/so too.
>
> I know this is not really clear

It would be helpful if you could write a paper, presenting your
examples and including a list of functions for which you really
need the answer.

>
> On 29 May 2013 21:24, Lawrence Crowl <crowl@googlers.com> wrote:
>> On 5/29/13, adrien courdavault <adrien59cadri@gmail.com> wrote:
>>> This seams to be a very simplistic request but I think it would be
>>> nice to have some traits to know if a function call is lock free
>>> or not.  It is not usefull for every function, but it could be
>>> for the class like thread obviously.  Clearly launching a thread
>>> is not, but depending on the implementation get_id could be;
>>>
>>> I say that because in time critical thread you want to know it
>>> it is safe to do that.  In my case i want to know if I am in the
>>> time critical thread, ... problem, if asking for the id of the
>>> thread is not lock free I might just have break the rule I wanted
>>> to inforce by asking if I was in this thread, what do you think?
>>
>> We might be able to provide this query definitively for a
>> pre-determined set of functions.  In general, though, I think we
>> would need to be able to answer "don't know".
>>
>> Do you have a list of other functions for which you must know?
>> Do you need a dynamic test, i.e. on a function pointer, or can
>> you live with a static test, i.e. on a template argument?
>>
>> --
>> Lawrence Crowl
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/2iCzaKc2PRE/unsubscribe?hl=en.
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>>
>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>


--
Lawrence Crowl

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_249_8538835.1369913394463
Content-Type: text/plain; charset=ISO-8859-1

So you're asking for standard library implementors to provide the answer
for every function in the std::lib (I would object strongly to being
required to do that) and that would only help for functions in namespace
std, it wouldn't give you an answer for system functions not defined by the
C++ standard e.g. POSIX functions such as ::usleep() and ::pthread_self(),
and even if you convince ever C and OS library vendor to implement it, that
wouldn't help for third-party libraries such as X toolkits or OpenGL
libraries or Boost libraries or the thousands of other libraries.  So would
it actually be useful?  It seems like it would be easier for you to just do
some homework to find out if the functions you need to use are lock-free on
the platforms you actually use, instead of pushing the work into the
standard.


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_249_8538835.1369913394463
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

So you're asking for standard library implementors to provide the answer fo=
r every function in the std::lib (I would object strongly to being required=
 to do that) and that would only help for functions in namespace std, it wo=
uldn't give you an answer for system functions not defined by the C++ stand=
ard e.g. POSIX functions such as ::usleep() and ::pthread_self(), and even =
if you convince ever C and OS library vendor to implement it, that wouldn't=
 help for third-party libraries such as X toolkits or OpenGL libraries or B=
oost libraries or the thousands of other libraries.  So would it actua=
lly be useful?  It seems like it would be easier for you to just do so=
me homework to find out if the functions you need to use are lock-free on t=
he platforms you actually use, instead of pushing the work into the standar=
d.<br><br><br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_249_8538835.1369913394463--

.

Hi

Sorry, I've probably not been really clear. I m not asking for all
functions to implement that. And I don't say that having the answer in
the std is the best solution.
But I is hard when you want to use std classes or functions in a
context and you are not sure of their behaviour.
For instance we know that const functions imply thread safety in
c++11, this gives me good information on how I can use it for
multithreaded context. For the lock free issue, their is no clue
currently.
I might or assume that nothing is lock free or try to find out what
is. As I was looking for this information, I discovered that the
implementation of std::thread::get_id  is probably using
::pthread_self on posix OSs, still then I don't know if it is thread
safe. I can go and find out if it is. BUT for non-opened libraries
(like MS libc) I can't go and check the code. So Or there is a
documentation of that, which is not always easy to find, Or there is
something in the std that could indicate this.

For instance, the atomic types have the method to know if the
atomicity is lockfree or not, therefor I thought it might be
interesting for several functions to have this info in a trait because
it will depend on the implementation.

I was talking about more general purpose of this approach just to know
if the idea of traits is a good one or not.
Thank you for the feedbacks.

Again this is just an idea to make it easier to use the std, in some cases

On 30 May 2013 13:29, Jonathan Wakely <cxx@kayari.org> wrote:
> So you're asking for standard library implementors to provide the answer for
> every function in the std::lib (I would object strongly to being required to
> do that) and that would only help for functions in namespace std, it
> wouldn't give you an answer for system functions not defined by the C++
> standard e.g. POSIX functions such as ::usleep() and ::pthread_self(), and
> even if you convince ever C and OS library vendor to implement it, that
> wouldn't help for third-party libraries such as X toolkits or OpenGL
> libraries or Boost libraries or the thousands of other libraries.  So would
> it actually be useful?  It seems like it would be easier for you to just do
> some homework to find out if the functions you need to use are lock-free on
> the platforms you actually use, instead of pushing the work into the
> standard.
>
>
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/2iCzaKc2PRE/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.