Send Boost-users mailing list submissions to
boost-users@lists.boost.orgTo subscribe or unsubscribe via the World Wide Web, visit
http://lists.boost.org/mailman/listinfo.cgi/boost-usersor, via email, send a message with subject or body 'help' to
boost-users-request@lists.boost.orgYou can reach the person managing the list at
boost-users-owner@lists.boost.orgWhen 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.orgSubject: 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_21773618There 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.orgSubject: 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_impThis 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.orgSubject: 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.orgSubject: 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.orghttp://lists.boost.org/mailman/listinfo.cgi/boost-users------------------------------
End of Boost-users Digest, Vol 4049, Issue 1
********************************************