headers
Matt Hurd | 1 Dec 2006 02:33
Picon
Favicon

Re: [boost.thread] Atomic condition notify/wait on anothercondition

>On 01/12/06, Yuval Ronen <ronen_yuval <at> yahoo.com> wrote:
<snip>
> If there aren't any, then why
> wouldn't the CV interface be changed to do the while loop itself:
>
> template <typename Lock, typename Pred>
> void condition::wait(Lock &lock, Pred while_cond)
> {
>      while (while_cond)
>      {
>          old_wait(lock);
>      }
> }
>
> or something similar.
>
> Does that make sense?

Good sense.  It is so:

>From http://www.boost.org/doc/html/condition.html

#2  template<typename ScopedLock, typename Pred>
  void wait(ScopedLock& lock, Pred pred);

Requires: ScopedLock meets the ScopedLock requirements and the return
from pred() is convertible to bool.
Effects: As if: while (!pred()) wait(lock)
Throws: lock_error if !lock.locked()
(Continue reading)

Permalink | Reply | 1 comment |
headers
Deane Yang | 1 Dec 2006 04:03
Picon
Favicon

Re: Yet another bignum type

Maarten Kronenburg wrote:
> 
> Here I disagree.
> The class represents the set, and an object of that class represents an
> element from that set,
> whether the set is employees and secretaries, or integers and unsigned
> integers.
> 

If C++ classes represent only sets of data and not their behavior, then 
there would not be any need for member functions. Neither would there be 
any need for the distinction between public and private members.

One would only need structs and free functions that act on them.

But maybe this argument has gone on too long. You should just proceed as 
you think best.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Yuval Ronen | 1 Dec 2006 10:24
Picon
Favicon

Re: [boost.thread] Atomic condition notify/wait on anothercondition

Matt Hurd wrote:
>> On 01/12/06, Yuval Ronen <ronen_yuval <at> yahoo.com> wrote:
> <snip>
>> If there aren't any, then why
>> wouldn't the CV interface be changed to do the while loop itself:
>>
>> template <typename Lock, typename Pred>
>> void condition::wait(Lock &lock, Pred while_cond)
>> {
>>      while (while_cond)
>>      {
>>          old_wait(lock);
>>      }
>> }
>>
>> or something similar.
>>
>> Does that make sense?
> 
> Good sense.  It is so:
> 
>>From http://www.boost.org/doc/html/condition.html
> 
> #2  template<typename ScopedLock, typename Pred>
>   void wait(ScopedLock& lock, Pred pred);
> 
> Requires: ScopedLock meets the ScopedLock requirements and the return
> from pred() is convertible to bool.
> Effects: As if: while (!pred()) wait(lock)
> Throws: lock_error if !lock.locked()
(Continue reading)

Permalink | Reply | 0 comments |
headers
Korcan Hussein | 1 Dec 2006 11:24
Picon
Favicon

Improving efficiency of multi_array

I had a look into multi_array's implementation and i can see a number of 
opportunities to improve  the efficiency multi_array perhaps by quite a lot 
with only very minor changes.

Why are we not taking advantage of the fact that that 
allocation/de-allocation is separate from construction/destruction? i see in 
a number of places that multi_array is redundantly default constructing 
elements (like in multi_array::allocate_space) and then copying new elements 
into the array for example in multi_array i see a lot of:

allocate_space();  // allocate memory then default construct
std::copy(rhs.begin(),rhs.end(),this->begin());

instead why not just do an in-place copy construction from the outset, 
something like:

allocate_space(); // a new version which only allocates memory, no 
construction
std::uninitialized_copy(rhs.begin(), rhs.end(), this->begin());

When i create a multi_array i want to be able to "reserve" the shape of  a 
multi_array and then incrementally add new elements via in-place copy 
construction or even better using in-place factories.

We do not even need to explicitly store the size if we take advantage of 
uninitialized and initialized elements, just like how modern implementations 
of std::vector do.

Another minor thing is to apply the empty member/base optimizations 
(EMO/EBO) for allocator types which are empty in size.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Roland Schwarz | 1 Dec 2006 11:33
Picon

[thread] Some thoughts about "atomic"

After having tried to learn about atomic from reading through several 
articles, processor specs and mailing lists, I am more confused than before.

I would be glad if we could (re)start a discussion about the topic. 
Perhaps I am not the only one to benefit from this.

Following are some things I learned, but this might be wrong, and I 
would appreciate clarification. Also some questions:

1)     atomicity (in this specialized context) is about optimizing the 
pattern: enter_critical_section; do_something; leave_critical_section; 
by making use of processor/platform specific means. In particular in 
presence of multiple processors. I.e. an atomic lib is primarily about 
performance.

2)     atomicity better would be addressed by the compiler, given a 
suitable memory model, than as a library.

3)     Despite 2) it would be possible to write a library, but it will 
be hard to get processor independent semantics. E.g. there is one 
concept of read/write/full memory barriers or another of acquire/release 
semantics for SMP.

4)     Does there exist a canonical set of atomic primitives, from which 
others can be built? E.g. given atomic_test_and_set, atomic_load and 
atomic_store is it possible to emulate atomic_compare_and_swap? (without 
use of system mutices of course.)

5)     Is it worth the effort to create a library with processor 
independent semantics, at the price of not being optimal? E.g. by doing
(Continue reading)

Permalink | Reply | 13 comments |
headers
Anthony Williams | 1 Dec 2006 12:27
Picon
Favicon

Re: [thread] Some thoughts about "atomic"

Roland Schwarz <roland.schwarz <at> chello.at> writes:

> I would be glad if we could (re)start a discussion about the topic. 
> Perhaps I am not the only one to benefit from this.

Sounds sensible.

> Following are some things I learned, but this might be wrong, and I 
> would appreciate clarification. Also some questions:
>
> 1)     atomicity (in this specialized context) is about optimizing the 
> pattern: enter_critical_section; do_something; leave_critical_section; 
> by making use of processor/platform specific means. 

Essentially, yes. Other CPUs/threads will either see the state before the
atomic op, or after, but never a "partial" effect.

On x86, normal reads and writes to suitably-aligned 32-bit values are atomic
in this sense.

> In particular in 
> presence of multiple processors. I.e. an atomic lib is primarily about 
> performance.

Not just about performance. It also enables the construction of the
higher-level primitives.

Atomic instructions also affect visibility, which is addressed below.

> 2)     atomicity better would be addressed by the compiler, given a
(Continue reading)

Permalink | Reply | 8 comments |
headers
Andreas Huber | 1 Dec 2006 12:47
Picon
Favicon

[detail] Added copyright to limits.hpp & endian.hpp

In an attempt to fix inspect failures I have added a boost license & 
copyright to the following files:

<http://boost.cvs.sourceforge.net/boost/boost/boost/detail/limits.hpp?r1=1.26&r2=1.27>
<http://boost.cvs.sourceforge.net/boost/boost/boost/detail/endian.hpp?r1=1.5&r2=1.6>

The copyright is attributed to John because he seems to have made most 
of the changes to the Silicon Graphics original.

If anybody feels that these changes are factually or legally wrong, 
please let me know.

Thanks,

--

-- 
Andreas Huber

When replying by private email, please remove the words spam and trap 
from the address shown in the header. 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 5 comments |
headers
Tobias Schwinger | 1 Dec 2006 12:57

Re: FW: Suggestion for boost`s smart pointers

Sohail Somani wrote:
> Please see the following email about additional template parameters for
> scoped_ptr. The quick hack I wrote for it is below (I've used this in
> previous project as well). I think it would be very useful to many users
> and wouldn't change any source using scoped_ptr.

This question makes me feel nostalgic. My first request on this list looked very 
similar (I needed to Release() COM objects). I just dug up the reply and it 
seems there used to be this kind of parametrized deletion for shared_ptr. 

I learned a lot about C++ design since then (not at least because of lurking in 
this unique and elite forum ;-) ) and I'd propose a different interface for that
feature today:

Actually, I don't think that parametrized deletion belongs into the interface of
a smart pointer. It's up to other components to have proper deletion semantics. 
Still, there sure are cases (dealing with third-party or plain C components) 
where it is a practical thing to have. So I'd probably ask for a freestanding 
function that is called without qualification to do the deletion (just using 
delete by default), so it can be overloaded and found via ADL and we don't need 
to change and mess up the interface of the smart pointer.

BTW. I just noticed there is some "get_deleter logic" (marked as experimental in
a comment) based on RTTI in 'shared_ptr.hpp'. What's that all about? Heap 
selection when using shared libraries?

Regards,

Tobias
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tobias Schwinger | 1 Dec 2006 13:06

Re: Yet another bignum type

OK, one last attempt (still hoping that the suspicion that this discussion might 
be about pure ignorance proves wrong).

Maarten Kronenburg wrote:
> The class represents the set, and an object of that class represents an
> element from that set,

Agreed, so far.

> whether the set is employees and secretaries, or integers and unsigned
> integers.

The operations on secretaries are usually a superset of the operations on employees, 
while the operations on unsigned integers are a subset of the operations on signed 
integers. 

Inheritance is only applicable in the former case. The flaw in the latter scenario
is similar to adding operations specific to secretaries, trainees or managers to 
the interface of 'employee'. 

Regards,

Tobias

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 4 comments |
headers
Pedro Lamarão | 1 Dec 2006 13:19
Picon

Re: [thread] Some thoughts about "atomic"

Roland Schwarz escreveu:

> 2)     atomicity better would be addressed by the compiler, given a 
> suitable memory model, than as a library.

> 3)     Despite 2) it would be possible to write a library, but it will 
> be hard to get processor independent semantics. E.g. there is one 
> concept of read/write/full memory barriers or another of acquire/release 
> semantics for SMP.

> 5)     Is it worth the effort to create a library with processor 
> independent semantics, at the price of not being optimal? E.g. by doing 
> away with the various kinds of barriers, instead simply requiring 
> atomicity and full memory barrier semantics for the operation? Which 
> operations, besides load and store would be essential?

The current working paper for the Standard Library contains chapter 29 
"Atomic operations library".

This chapter currently contains only a forward declaration (hehe) to the 
  draft proposal by Hans Bohem.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2047.html

It's sister paper, "Sequencing and the concurrency memory model", is:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2052.htm

--
  Pedro Lamarão
(Continue reading)

Permalink | Reply | 2 comments |

Gmane