That is the problem. My plugins are calling routing engine from their own threads.

How you can ensure that nobody will do it?
Routing engine e has to be thread safe.

How I can  call routing engine from ambd main thread, If I have separate thread for receiving CAN frames???

Marek

On Jun 25, 2014 2:35 AM, <amb-request@lists.01.org> wrote:
Send AMB mailing list submissions to
        amb@lists.01.org

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

You can reach the person managing the list at
        amb-owner@lists.01.org

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


Today's Topics:

   1. Re: AMB Performance (Rees, Kevron)
   2. Re: AMB Performance (Marek Timko)
   3. Re: AMB Performance (Kevron Rees)


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

Message: 1
Date: Tue, 24 Jun 2014 13:22:15 -0700
From: "Rees, Kevron" <kevron.m.rees@intel.com>
To: Marek Timko <marek.timko1@gmail.com>
Cc: amb@lists.01.org
Subject: Re: [AMB] AMB Performance
Message-ID:
        <CAFW5wYZEhm8D9jR7p3Ysk6UJReien9-4jrhRcyZc9hf0G-V2dA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On Tue, Jun 24, 2014 at 11:21 AM, Rees, Kevron <kevron.m.rees@intel.com> wrote:
> On Tue, Jun 24, 2014 at 10:11 AM, Marek Timko <marek.timko1@gmail.com> wrote:
>> Hi,
>>
>> I checked the latest code and I see 2 issues that can cause a crash.
>> Both related to DBus signaler.
>> 1. You have to protect queue with mutex,
>> because timer may be called from different thread than thread in which you
>> are inserting into queue.
>
> Right now it all happens in the same thread.  When would it not be in
> the same thread?
>
>> 2. AbstractType::setValue does delete mValue and set the new pointer. From
>> dbus signaler you are accessing mValue. I can reproduce crash in < 50ms when
>> changing property every 1 ms.
>>
>
> Good catch.  I'll look into it.

What's the best way to reproduce it.  I've got the following config
and I'm not able to reproduce it...  It could be that my local changes
are obfuscating reproduction though...

{
        "sources" : [
                {
                        "name" : "ExampleSouce",
                        "path" :
"/usr/lib/automotive-message-broker/examplesourceplugin.so",
                        "delay" : "0"
                }
        ],
        "sinks": [
                {
                        "name" : "DBusSink",
                        "path" :
"/usr/lib/automotive-message-broker/dbussinkplugin.so",
                        "frequency" : "60"
                }

        ]
}


>
>> I did some performance improvement, but I haven't been able to compare
>> because of the crash of the original code :-)
>>
>> Marek
>>
>> On Jun 11, 2014 9:41 PM, "Marek Timko" <marek.timko1@gmail.com> wrote:
>>>
>>> Just came to my mind: I have a very good experience with Intel VTune  ;-)
>>> It was on Windows, but it's available also for Linux.
>>>
>>> https://software.intel.com/en-us/intel-vtune-amplifier-xe
>>>
>>> It's able to to show CPU usage per function.
>>>
>>> Marek
>>>
>>> On Tue, Jun 10, 2014 at 12:47 AM, marek.timko1@gmail.com
>>> <marek.timko1@gmail.com> wrote:
>>> >
>>> > Hi Kevron,
>>> > I see that there is still 8-9% CPU usage in performance
>>> > test(https://bugs.tizen.org/jira/browse/TIVI-2623).
>>>
>>> I haven't pushed some of the more impactful changes to tizen yet.  So
>>> the most recent test doesn't include those (0.11.809 vs 810).
>>>
>>> > I suggest to use valgrind with callgrind plugin(--tool=callgrind).
>>> > QtCreator has a nice support plugin for valgrind.
>>> > You can find tho most often called methods(and time consumption) and
>>> > improove the most critical then.
>>> >
>>>
>>> Agreed.  I do use that tool in QtCreator.  It's very nice.  There's a
>>> lot of data to sift through.  So far I've only been addressing the
>>> biggest pigs I can find, which are typically related to DBus usage.
>>> But as that becomes less of an issue, I'll have to use the tools to
>>> find smaller "pigs".
>>>
>>> > And I still think that you should replace all method calls with
>>> > arguments
>>> > passed by value with arguments passed by (const) reference. At least
>>> > those
>>> > under lib folder - it affect all plugins and can be called very often.
>>> > For example AbstractRoutingEngine::setProperty(AsyncSetPropertyRequest
>>> > request) is called for every signal change, If I remember correctly.
>>> > It also should reduce CPU usage. ( Imagine std::string -> there is
>>> > always at
>>> > least one malloc, one memcopy and one free call for each method call
>>> > with
>>> > arguments passed by value for each std::string argument).
>>> >
>>>
>>> Agreed.  Passing by const ref makes sense.
>>>
>>> > Marek.
>>> >
>>> > Sent from my mobile
>>> >
>>> > _______________________________________________
>>> > AMB mailing list
>>> > AMB@lists.01.org
>>> > https://lists.01.org/mailman/listinfo/amb
>>> >


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

Message: 2
Date: Tue, 24 Jun 2014 22:49:49 +0200
From: Marek Timko <marek.timko1@gmail.com>
To: "Rees, Kevron" <kevron.m.rees@intel.com>
Cc: amb@lists.01.org
Subject: Re: [AMB] AMB Performance
Message-ID:
        <CADNADdEHBG04qdi3jCR-Bpiu5mj6bvc7Y=2eoJzn=R3rLs0R6g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I used can plugin (source plugin, can be cansimplugin) and canplay utility(
from can-utils) to send ~1000 can frames / changes of the VehicleSpeed per
second.
On Jun 24, 2014 10:22 PM, "Rees, Kevron" <kevron.m.rees@intel.com> wrote:

> On Tue, Jun 24, 2014 at 11:21 AM, Rees, Kevron <kevron.m.rees@intel.com>
> wrote:
> > On Tue, Jun 24, 2014 at 10:11 AM, Marek Timko <marek.timko1@gmail.com>
> wrote:
> >> Hi,
> >>
> >> I checked the latest code and I see 2 issues that can cause a crash.
> >> Both related to DBus signaler.
> >> 1. You have to protect queue with mutex,
> >> because timer may be called from different thread than thread in which
> you
> >> are inserting into queue.
> >
> > Right now it all happens in the same thread.  When would it not be in
> > the same thread?
> >
> >> 2. AbstractType::setValue does delete mValue and set the new pointer.
> From
> >> dbus signaler you are accessing mValue. I can reproduce crash in < 50ms
> when
> >> changing property every 1 ms.
> >>
> >
> > Good catch.  I'll look into it.
>
> What's the best way to reproduce it.  I've got the following config
> and I'm not able to reproduce it...  It could be that my local changes
> are obfuscating reproduction though...
>
> {
>         "sources" : [
>                 {
>                         "name" : "ExampleSouce",
>                         "path" :
> "/usr/lib/automotive-message-broker/examplesourceplugin.so",
>                         "delay" : "0"
>                 }
>         ],
>         "sinks": [
>                 {
>                         "name" : "DBusSink",
>                         "path" :
> "/usr/lib/automotive-message-broker/dbussinkplugin.so",
>                         "frequency" : "60"
>                 }
>
>         ]
> }
>
>
> >
> >> I did some performance improvement, but I haven't been able to compare
> >> because of the crash of the original code :-)
> >>
> >> Marek
> >>
> >> On Jun 11, 2014 9:41 PM, "Marek Timko" <marek.timko1@gmail.com> wrote:
> >>>
> >>> Just came to my mind: I have a very good experience with Intel VTune
>  ;-)
> >>> It was on Windows, but it's available also for Linux.
> >>>
> >>> https://software.intel.com/en-us/intel-vtune-amplifier-xe
> >>>
> >>> It's able to to show CPU usage per function.
> >>>
> >>> Marek
> >>>
> >>> On Tue, Jun 10, 2014 at 12:47 AM, marek.timko1@gmail.com
> >>> <marek.timko1@gmail.com> wrote:
> >>> >
> >>> > Hi Kevron,
> >>> > I see that there is still 8-9% CPU usage in performance
> >>> > test(https://bugs.tizen.org/jira/browse/TIVI-2623).
> >>>
> >>> I haven't pushed some of the more impactful changes to tizen yet.  So
> >>> the most recent test doesn't include those (0.11.809 vs 810).
> >>>
> >>> > I suggest to use valgrind with callgrind plugin(--tool=callgrind).
> >>> > QtCreator has a nice support plugin for valgrind.
> >>> > You can find tho most often called methods(and time consumption) and
> >>> > improove the most critical then.
> >>> >
> >>>
> >>> Agreed.  I do use that tool in QtCreator.  It's very nice.  There's a
> >>> lot of data to sift through.  So far I've only been addressing the
> >>> biggest pigs I can find, which are typically related to DBus usage.
> >>> But as that becomes less of an issue, I'll have to use the tools to
> >>> find smaller "pigs".
> >>>
> >>> > And I still think that you should replace all method calls with
> >>> > arguments
> >>> > passed by value with arguments passed by (const) reference. At least
> >>> > those
> >>> > under lib folder - it affect all plugins and can be called very
> often.
> >>> > For example
> AbstractRoutingEngine::setProperty(AsyncSetPropertyRequest
> >>> > request) is called for every signal change, If I remember correctly.
> >>> > It also should reduce CPU usage. ( Imagine std::string -> there is
> >>> > always at
> >>> > least one malloc, one memcopy and one free call for each method call
> >>> > with
> >>> > arguments passed by value for each std::string argument).
> >>> >
> >>>
> >>> Agreed.  Passing by const ref makes sense.
> >>>
> >>> > Marek.
> >>> >
> >>> > Sent from my mobile
> >>> >
> >>> > _______________________________________________
> >>> > AMB mailing list
> >>> > AMB@lists.01.org
> >>> > https://lists.01.org/mailman/listinfo/amb
> >>> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.01.org/pipermail/amb/attachments/20140624/3255cdb2/attachment-0001.html>

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

Message: 3
Date: Tue, 24 Jun 2014 17:35:03 -0700
From: Kevron Rees <tripzero.kev@gmail.com>
To: Marek Timko <marek.timko1@gmail.com>
Cc: amb@lists.01.org
Subject: Re: [AMB] AMB Performance
Message-ID:
        <CAAOZRYVRBjp6Q6iof109GitxyjHXn2EtB+C-O-jcEBPpketu-g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Delay 0 produces about 300k changes in the example source.  I'm not hitting
a crash.  Signaller uses the abstractproperty.  So it shouldn't ever crash
unless it was being changed by a different thread at the same time as the
signal was being fired...

Plugins shouldn't be calling any routing engine calls from different
threads.  RoutingEngine is not thread safe
On Jun 24, 2014 1:50 PM, "Marek Timko" <marek.timko1@gmail.com> wrote:

> I used can plugin (source plugin, can be cansimplugin) and canplay
> utility( from can-utils) to send ~1000 can frames / changes of the
> VehicleSpeed per second.
> On Jun 24, 2014 10:22 PM, "Rees, Kevron" <kevron.m.rees@intel.com> wrote:
>
>> On Tue, Jun 24, 2014 at 11:21 AM, Rees, Kevron <kevron.m.rees@intel.com>
>> wrote:
>> > On Tue, Jun 24, 2014 at 10:11 AM, Marek Timko <marek.timko1@gmail.com>
>> wrote:
>> >> Hi,
>> >>
>> >> I checked the latest code and I see 2 issues that can cause a crash.
>> >> Both related to DBus signaler.
>> >> 1. You have to protect queue with mutex,
>> >> because timer may be called from different thread than thread in which
>> you
>> >> are inserting into queue.
>> >
>> > Right now it all happens in the same thread.  When would it not be in
>> > the same thread?
>> >
>> >> 2. AbstractType::setValue does delete mValue and set the new pointer.
>> From
>> >> dbus signaler you are accessing mValue. I can reproduce crash in <
>> 50ms when
>> >> changing property every 1 ms.
>> >>
>> >
>> > Good catch.  I'll look into it.
>>
>> What's the best way to reproduce it.  I've got the following config
>> and I'm not able to reproduce it...  It could be that my local changes
>> are obfuscating reproduction though...
>>
>> {
>>         "sources" : [
>>                 {
>>                         "name" : "ExampleSouce",
>>                         "path" :
>> "/usr/lib/automotive-message-broker/examplesourceplugin.so",
>>                         "delay" : "0"
>>                 }
>>         ],
>>         "sinks": [
>>                 {
>>                         "name" : "DBusSink",
>>                         "path" :
>> "/usr/lib/automotive-message-broker/dbussinkplugin.so",
>>                         "frequency" : "60"
>>                 }
>>
>>         ]
>> }
>>
>>
>> >
>> >> I did some performance improvement, but I haven't been able to compare
>> >> because of the crash of the original code :-)
>> >>
>> >> Marek
>> >>
>> >> On Jun 11, 2014 9:41 PM, "Marek Timko" <marek.timko1@gmail.com> wrote:
>> >>>
>> >>> Just came to my mind: I have a very good experience with Intel VTune
>>  ;-)
>> >>> It was on Windows, but it's available also for Linux.
>> >>>
>> >>> https://software.intel.com/en-us/intel-vtune-amplifier-xe
>> >>>
>> >>> It's able to to show CPU usage per function.
>> >>>
>> >>> Marek
>> >>>
>> >>> On Tue, Jun 10, 2014 at 12:47 AM, marek.timko1@gmail.com
>> >>> <marek.timko1@gmail.com> wrote:
>> >>> >
>> >>> > Hi Kevron,
>> >>> > I see that there is still 8-9% CPU usage in performance
>> >>> > test(https://bugs.tizen.org/jira/browse/TIVI-2623).
>> >>>
>> >>> I haven't pushed some of the more impactful changes to tizen yet.  So
>> >>> the most recent test doesn't include those (0.11.809 vs 810).
>> >>>
>> >>> > I suggest to use valgrind with callgrind plugin(--tool=callgrind).
>> >>> > QtCreator has a nice support plugin for valgrind.
>> >>> > You can find tho most often called methods(and time consumption) and
>> >>> > improove the most critical then.
>> >>> >
>> >>>
>> >>> Agreed.  I do use that tool in QtCreator.  It's very nice.  There's a
>> >>> lot of data to sift through.  So far I've only been addressing the
>> >>> biggest pigs I can find, which are typically related to DBus usage.
>> >>> But as that becomes less of an issue, I'll have to use the tools to
>> >>> find smaller "pigs".
>> >>>
>> >>> > And I still think that you should replace all method calls with
>> >>> > arguments
>> >>> > passed by value with arguments passed by (const) reference. At least
>> >>> > those
>> >>> > under lib folder - it affect all plugins and can be called very
>> often.
>> >>> > For example
>> AbstractRoutingEngine::setProperty(AsyncSetPropertyRequest
>> >>> > request) is called for every signal change, If I remember correctly.
>> >>> > It also should reduce CPU usage. ( Imagine std::string -> there is
>> >>> > always at
>> >>> > least one malloc, one memcopy and one free call for each method call
>> >>> > with
>> >>> > arguments passed by value for each std::string argument).
>> >>> >
>> >>>
>> >>> Agreed.  Passing by const ref makes sense.
>> >>>
>> >>> > Marek.
>> >>> >
>> >>> > Sent from my mobile
>> >>> >
>> >>> > _______________________________________________
>> >>> > AMB mailing list
>> >>> > AMB@lists.01.org
>> >>> > https://lists.01.org/mailman/listinfo/amb
>> >>> >
>>
>
> _______________________________________________
> AMB mailing list
> AMB@lists.01.org
> https://lists.01.org/mailman/listinfo/amb
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.01.org/pipermail/amb/attachments/20140624/29eb02ea/attachment.html>

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

Subject: Digest Footer

_______________________________________________
AMB mailing list
AMB@lists.01.org
https://lists.01.org/mailman/listinfo/amb


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

End of AMB Digest, Vol 3, Issue 5
*********************************