headers
Ronald Garcia | 1 Aug 2011 04:51
Picon
Favicon

Re: what happened to context mini-review?

Hi Nate,

The review has been postponed, by request of the library author and review manager.

Best,
Ron

On Jul 31, 2011, at 6:46 PM, Nathan Ridge wrote:

> 
> Hello,
> 
> Up until a few days ago, the Review Schedule contained an entry
> for the mini-review of the Context library (which has previously
> been accepted provisionally) starting from July 28. Now the entry
> is gone and there is no sign of a mini-review on the list.
> 
> What is the status of the library? Has the mini-review been
> postponed? Or will the library be accepted without a mini-review?
> 
> Thanks,
> Nate 		 	   		  
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Gordon Woodhull | 1 Aug 2011 08:38
Favicon
Gravatar

Re: [lockfree] review


On Jul 31, 2011, at 1:05 PM, Dave Abrahams wrote:

>> 
>> and threads may see each others' actions in the wrong order, so a
>> weak memory model can actually break invariants even if the code is
>> good.
> 
> I don't get it.  Please, show me an example.

I am definitely not an expert.  I'll quote a diagram from this fascinating paper by Adve and Boehm [1], using
Dekker's mutual exclusion algorithm as an example

Initially X = Y = 0
Thread 1
X = 1;
r1 = Y;

Thread 2
Y = 1;
r2 = X;

Can r1 = r2 = 0?

And they give various reasons why the processor might reorder the instructions.  After all, with each
thread considered its own program, there is no dependency between X and Y that should mean it's incorrect
to reverse the operations.

> Anyway, what's the "wrong order?"  If one thread is depending on the
> order of things that happen in another thread without both threads using
(Continue reading)

Permalink | Reply | 44 comments |
headers
Tim Blechmann | 1 Aug 2011 14:50
Favicon
Gravatar

Re: [lockfree] review

[quick post, have some more in my outbox, but i'm at a conference this week,
where they cut imap/smtp ports]

>> Anyway, what's the "wrong order?"  If one thread is depending on the
>> order of things that happen in another thread without both threads using
>> the synchronization necessary to ensure that order, it's a race
>> condition (a.k.a. a bug), right?
>
> All of the classic lock-free algorithms, including those that are  
> the basis for the synchronization primitives we should usually use,  
> have data races.  At a low level it is sometimes necessary to use a  
> variable for synchronization.

the fifo code for example contains code like:

atomic<> head_, tail_;

head = head_.load();
tail = tail_.load();

head2 = head_.load();

if (head == head2)
    do something

the correctness of this algorithm depends on the order of the loads: load head
before tail and load tail before head2. without a memory model, both  
the compiler
and the CPU are allowed to reorder loads (or head2 could simply use  
the value of
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dave Abrahams | 1 Aug 2011 16:49
Picon
Picon
Favicon
Gravatar

Re: [lockfree] review


on Mon Aug 01 2011, Gordon Woodhull <gordon-AT-woodhull.com> wrote:

> On Jul 31, 2011, at 1:05 PM, Dave Abrahams wrote:
>
>>> 
>>> and threads may see each others' actions in the wrong order, so a
>>> weak memory model can actually break invariants even if the code is
>>> good.
>> 
>> I don't get it.  Please, show me an example.
>
> I am definitely not an expert.  I'll quote a diagram from this
> fascinating paper by Adve and Boehm [1], using Dekker's mutual
> exclusion algorithm as an example
>
> Initially X = Y = 0
> Thread 1
> X = 1;
> r1 = Y;
>
> Thread 2
> Y = 1;
> r2 = X;
>
> Can r1 = r2 = 0?

Sure they can, that's a race condition: Thread1 modifies X while thread
2 reads it.  Anything could happen.  Why would anyone expect otherwise.
(Continue reading)

Permalink | Reply | 39 comments |
headers
Daniel Larimer | 1 Aug 2011 16:55
Picon

Re: [reflect] Introducing Boost.Reflect

On Sun, Jul 31, 2011 at 4:11 AM, Matus Chochlik <chochlik <at> gmail.com> wrote:

> Hi Daniel,
>
> On Sat, Jul 30, 2011 at 11:05 PM, Daniel Larimer <dlarimer <at> gmail.com>
> wrote:
> > On Jul 30, 2011, at 4:40 AM, Jose wrote:
> >
> >>
> >> I hope you propose boost::reflect for review soon and then mature all
> >> the other bits in a library that enables other concurrency models and
> >> is a good brother for asio.
> >
> >>
> >
> > I take it as a high complement that you consider boost::reflect worthy to
> be considered for review soon.  I am willing to submit it if I can can get
> enough feedback on it.
>
> Your RPC library certainly looks interesting,
> but I've a few questions/comments
> on the reflection part.
>
> >
> > 1) Does the name describe what it does?
>
> Basically yes, but from a quick glance at the docs
> I'm missing a few things (see below).
> Generally from my own experience I can say
> that a reflection library should not start as
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dave Abrahams | 1 Aug 2011 17:00
Picon
Picon
Favicon
Gravatar

Re: [lockfree] review


on Mon Aug 01 2011, Tim Blechmann <tim-AT-klingt.org> wrote:

> [quick post, have some more in my outbox, but i'm at a conference this week,
> where they cut imap/smtp ports]
>
>>> Anyway, what's the "wrong order?"  If one thread is depending on the
>>> order of things that happen in another thread without both threads using
>>> the synchronization necessary to ensure that order, it's a race
>>> condition (a.k.a. a bug), right?
>>
>> All of the classic lock-free algorithms, including those that are
>> the basis for the synchronization primitives we should usually use,
>> have data races.  At a low level it is sometimes necessary to use a
>> variable for synchronization.
>
> the fifo code for example contains code like:
>
> atomic<> head_, tail_;
>
> head = head_.load();
> tail = tail_.load();
>
> head2 = head_.load();
>
> if (head == head2)
>    do something
>
> the correctness of this algorithm depends on the order of the loads: load head
> before tail and load tail before head2. without a memory model, both
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dominique Devienne | 1 Aug 2011 17:26
Picon
Gravatar

Re: [reflect] Introducing Boost.Reflect

On Mon, Aug 1, 2011 at 9:55 AM, Daniel Larimer <dlarimer <at> gmail.com> wrote:
> The last thing I want as an end-user is to specify  BOOST_REFLECT...,
> BOOST_MIRROR..., and BOOST_FUSION... for all of their types.

Indeed.

> I suspect there is a place for all 3 solutions as they all make different
> tradeoffs in performance, flexibility, and compile times.

+1. My $0.02. --DD
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Pierre Talbot | 1 Aug 2011 21:15
Picon

[Boost] [GSoC] [Checks] Issue with the design

Hello everyone.

We talked a few days ago about the design of the check library (about
the compile or run-time weight parameter.)
Reminder : the weights are the contribution to the running sum of a
digit in a number.

I used and followed your ideas and suggestions that bring me to the
policies class.

I tried to extract the characteristics of a "generic" check and the
weight is one of these. So I tried to implement the weight policy
class :

#define _WEIGHT_factory(z,n,unused) \
  template<BOOST_PP_ENUM_PARAMS(n, int weight)> \
  struct weight_policy \
  { typedef typename boost::mpl::vector_c<int BOOST_PP_COMMA_IF(n)
BOOST_PP_ENUM_PARAMS(n, weight)> weight ; } ; \

BOOST_PP_REPEAT_FROM_TO(1,BOOST_CHECK_LIMIT_WEIGHTS,_WEIGHT_factory,~)

#undef _WEIGHT_factory

But the compiler doesn't like the "struct template parameter
overloading". Is a limit of the language ? Or am I doing it in the
wrong way ?
If it's impossible, I though that we could passed the weights to a
function that aimed to "build" the vector_c type.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gordon Woodhull | 1 Aug 2011 22:08
Favicon
Gravatar

Re: [lockfree] review


On Aug 1, 2011, at 10:49 AM, Dave Abrahams wrote:
> on Mon Aug 01 2011, Gordon Woodhull <gordon-AT-woodhull.com> wrote:
>> All of the classic lock-free algorithms, including those that are the
>> basis for the synchronization primitives we should usually use, have
>> data races.  
> 
> IIUC, accesses to atomics are not in and of themselves data races.  But
> it doesn't surprise me a bit to learn (again) that lock-free algorithms
> are hard to think about.

This is the part of the theory that seems like a cop-out to me.  You can declare certain variables to be
atomic/for synchronization and then *by definition* it's not a data race?  Excuse me?  No.  It's still a
race, but it's one that's condoned because you've told the implementation that you want it to be there.

Of limited usefulness maybe.  But the brilliant insight is that there is finally a way to tell the
implementation which parts of the program order must be obeyed.

>> At a low level it is sometimes necessary to use a variable for
>> synchronization.
> 
> Sure, an atomic variable.  And along with those come associated memory
> barrier effects, right?

Yes.  The nice thing about the new system is that you describe the barrier effect that you want for the
accesses, with a default of sequential consistency.  Instead of having plain atomic operations and
having to guess where to put the barriers.  

>> "To write Figure 1 correctly under data-race-free, we need simply
>> identify the shared variables X and Y as synchronization variables.
(Continue reading)

Permalink | Reply | 34 comments |
headers
Helge Bahmann | 1 Aug 2011 22:56

Boost.Atomic, pushing forward and a little request for help

Hi folks,

from the comments to Boost.Lockfree I understand that you consider a 
non-reviewed Boost.Atomic as a "blocker"? I apologize that I have not pushed 
forward for review (considering that "it just works for me", and considering 
the length of the review queue...), but if you consider it blocking please 
just let me know what I would need to do to clear the path.

What I will do shortly is to provide and uptodate package containing several 
fixes, several contributed by others (they are in the repo, but not in any 
release archive) as well as some missing bits to more closely match latest 
C++0X draft.

The big sore point is still support for the various flavours of VC -- I know 
that there are (especially older) versions for which it is not working, but I 
am lacking test systems, so if you are affected please let me know and I will 
do my best to resolve the issues.

Cheers,
Helge
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 14 comments |

Gmane