Thanks Howard !


On Monday, February 9, 2015 12:00 PM, "boost-users-request@lists.boost.org" <boost-users-request@lists.boost.org> wrote:


Send Boost-users mailing list submissions to
    boost-users@lists.boost.org

To subscribe or unsubscribe via the World Wide Web, visit
    http://lists.boost.org/mailman/listinfo.cgi/boost-users
or, via email, send a message with subject or body 'help' to
    boost-users-request@lists.boost.org

You can reach the person managing the list at
    boost-users-owner@lists.boost.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Boost-users digest..."


Today's Topics:

  1. Re: Signals2 benchmark (Klaim - Jo?l Lamotte)
  2. Re: Signals2 benchmark (Michael Powell)
  3. write starvation of upgradable lock (David Frank)
  4. Re: write starvation of upgradable lock (Howard Hinnant)
  5. Re: Signals2 benchmark (Nevin Liber)
  6. Re: [Serialization] XML: float format is scientific instead
      of human-readable since Boost 1.57 (Frank St?hr)
  7. Re: Signals2 benchmark (Dominique Devienne)


----------------------------------------------------------------------

Message: 1
Date: Sun, 8 Feb 2015 18:49:06 +0100
From: Klaim - Jo?l Lamotte <mjklaim@gmail.com>
To: Boost users list <boost-users@lists.boost.org>
Subject: Re: [Boost-users] Signals2 benchmark
Message-ID:
    <CAOU91ON-+ywWjniue3n56sYSy2ZALtYykDN9ehLp4Qcm6BYoxg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Sun, Feb 8, 2015 at 4:42 PM, Michael Powell <mwpowellhtx@gmail.com>
wrote:

> On Sun, Feb 8, 2015 at 8:02 AM, Klaim - Jo?l Lamotte <mjklaim@gmail.com>
> wrote:
> >
> >
> > An executor takes arbitrary tasks as input and only
> > guarantee that these tasks will be executed, under some constraints
> > defined by the specific executor type.
> > A signal dispatch it's call and parametters to a set of observers.
>
> Using the Boost.Signals2 for example, it is easy AFAIK to type-define
> a signal, and re-use that type anywhere that signal is required. So a
> listener could receive a signal, and subsequently do whatever it
> wanted to with that message; dispatch it again, process it,
> whatever...
>
>
Yes but the executor would specify how the observers are notified, not how
the observer's work is executed (which depends on the observer
implementation indeed).
There is an important nuance here.
-------------- next part --------------
HTML attachment scrubbed and removed

------------------------------

Message: 2
Date: Sun, 8 Feb 2015 12:13:36 -0600
From: Michael Powell <mwpowellhtx@gmail.com>
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] Signals2 benchmark
Message-ID:
    <CAMEoF_EPGGUVeGXD2GA6AWbynKwXOu6Hfm9Nu+1nDioB1OxmAg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On Sun, Feb 8, 2015 at 11:49 AM, Klaim - Jo?l Lamotte <mjklaim@gmail.com> wrote:
>
>
> On Sun, Feb 8, 2015 at 4:42 PM, Michael Powell <mwpowellhtx@gmail.com>
> wrote:
>>
>> On Sun, Feb 8, 2015 at 8:02 AM, Klaim - Jo?l Lamotte <mjklaim@gmail.com>
>> wrote:
>> >
>> >
>> > An executor takes arbitrary tasks as input and only
>> > guarantee that these tasks will be executed, under some constraints
>> > defined by the specific executor type.
>> > A signal dispatch it's call and parametters to a set of observers.
>>
>> Using the Boost.Signals2 for example, it is easy AFAIK to type-define
>> a signal, and re-use that type anywhere that signal is required. So a
>> listener could receive a signal, and subsequently do whatever it
>> wanted to with that message; dispatch it again, process it,
>> whatever...
>>
>
> Yes but the executor would specify how the observers are notified, not how
> the observer's work is executed (which depends on the observer
> implementation indeed).
> There is an important nuance here.

Yes, I understand. See prior note concerning Dispatcher interfaces.
Not sure that there is such an animal in the current Boost.Signals2
version, per se. A default Dispatcher might be synchronous, whereas an
asynchronous Dispatcher could be provided. I am at best intermediate
knowledge where async, futures, promises are concerned, or if
something like that is even possible with Signals2.

> _______________________________________________
> Boost-users mailing list
> Boost-users@lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/boost-users


------------------------------

Message: 3
Date: Sun, 8 Feb 2015 23:38:40 +0000 (UTC)
From: David Frank <david_frank56@yahoo.com>
To: "boost-users@lists.boost.org" <boost-users@lists.boost.org>
Subject: [Boost-users] write starvation of upgradable lock
Message-ID:
    <1997263271.1635544.1423438720445.JavaMail.yahoo@mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"

From this discussion,
http://stackoverflow.com/questions/21773618/starvation-with-upgrade-lock?noredirect=1#comment32949054_21773618
There seems to be a starvation of writer with upgradable lock, I'm wondering if there is any fix/improvement with later release, e.g, 1.56, or 1.57
Thanks,David
-------------- next part --------------
HTML attachment scrubbed and removed

------------------------------

Message: 4
Date: Sun, 8 Feb 2015 19:57:56 -0500
From: Howard Hinnant <howard.hinnant@gmail.com>
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] write starvation of upgradable lock
Message-ID: <9738B571-4601-4425-96D4-18263C3AB43F@gmail.com>
Content-Type: text/plain; charset=us-ascii


On Feb 8, 2015, at 6:38 PM, David Frank <david_frank56@yahoo.com> wrote:

> From this discussion,
>
> http://stackoverflow.com/questions/21773618/starvation-with-upgrade-lock?noredirect=1#comment32949054_21773618
>
> There seems to be a starvation of writer with upgradable lock, I'm wondering if there is any fix/improvement with later release, e.g, 1.56, or 1.57

More info:  The fair Terekhov algorithm is trivially adaptable to upgrade_mutex as shown in this paper from 2007:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html#upgrade_mutex_imp

This code is in the public domain.  Please take it.

Howard



------------------------------

Message: 5
Date: Sun, 8 Feb 2015 19:25:34 -0600
From: Nevin Liber <nevin@eviloverlord.com>
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] Signals2 benchmark
Message-ID:
    <CAGg_6+Ov8o1Ex3oNSfjt1WL6YaKoOO6dN7dKD7PYatxcU3j7ig@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On 7 February 2015 at 10:20, Niall Douglas <s_sourceforge@nedprod.com>
wrote:

> On 7 Feb 2015 at 3:12, Eric Prud'hommeaux wrote:
>
> > > But comparing thread-safe implementations with implementations that
> > > are not thread-safe seems a bit unfair to me.
> >
> > Is it reallistic that folks would want a variant of signals that's not
> > threadsafe, trading some callback restrictions for performance?
>
> I think a version which is compile time switchable is the ideal.
>

-1.

Unless you can always build everything from source (as opposed to linking
against libraries built by others), this becomes a nightmare when trying to
avoid ODR violations.
--
Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
-------------- next part --------------
HTML attachment scrubbed and removed

------------------------------

Message: 6
Date: Mon, 09 Feb 2015 10:33:40 +0100
From: Frank St?hr <staehr@nue.tu-berlin.de>
To: boost-users@lists.boost.org
Subject: Re: [Boost-users] [Serialization] XML: float format is
    scientific instead of human-readable since Boost 1.57
Message-ID: <54D87EF4.7010209@nue.tu-berlin.de>
Content-Type: text/plain; charset=utf-8; format=flowed

On 30.01.2015 at 17:27, Robert Ramey wrote:
> So I'm willing to consider accommodating this request. The real question is:
> is it sufficiently important for you to do the work or only important enough
> for me to do the work?

No.


------------------------------

Message: 7
Date: Mon, 9 Feb 2015 12:00:08 +0100
From: Dominique Devienne <ddevienne@gmail.com>
To: boost-users <boost-users@lists.boost.org>
Subject: Re: [Boost-users] Signals2 benchmark
Message-ID:
    <CAFCRh--UQ9fZZjoD4m+beMR4Dpt_1Y+HDKRO_EEfBh45D+8Dww@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Fri, Feb 6, 2015 at 8:18 PM, Niall Douglas <s_sourceforge@nedprod.com>
wrote:

> An atomic increment/decrement use count maybe? Slow when contended,
> but faster possibly than alternatives.
>
> BTW you can fold a lock into a pointer by using its bottom bit as the
> lock bit. I have an implementation in Boost.Spinlock if you want it.
>

There's also
https://github.com/facebook/folly/blob/master/folly/PackedSyncPtr.h, FWIW.
--DD
-------------- next part --------------
HTML attachment scrubbed and removed

------------------------------

Subject: Digest Footer

_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

------------------------------

End of Boost-users Digest, Vol 4049, Issue 1
********************************************