Managing TimeService resources

Hi,

I'm wondering how to properly manage the resources and lifecycle of a
RTT::os::TimeService instance. Considering that:

- TimeService is a singleton, and resources are dynamically allocated the
first time TimeService::Instance() is called.

- TimeService::Release() frees currently allocated resources, if any.

How can I manage the lifecycle of this singleton when there is more than
one client in the same process, and they don't know about each other?. What
I'm potentially trying to avoid is something like:

- Client A initializes the TimeService and starts using it in a realtime
context.
- Client B initializes the TimeService (no-op, as A already did this) and
starts using it in a realtime context.
- Client A is done and calls TimeService::Release()
- Client B tries to use the time service and ends up allocating resources
in a realtime context

What other solutions are there apart from assuming a memory leak or a
potential mode switch?.

TIA,

Managing TimeService resources

Hi Adolfo,

On Thu, May 16, 2013 at 3:28 PM, Adolfo Rodríguez Tsouroukdissian <
adolfo [dot] rodriguez [..] ...> wrote:

> Hi,
>
> I'm wondering how to properly manage the resources and lifecycle of a
> RTT::os::TimeService instance. Considering that:
>
> - TimeService is a singleton, and resources are dynamically allocated the
> first time TimeService::Instance() is called.
>
> - TimeService::Release() frees currently allocated resources, if any.
>
> How can I manage the lifecycle of this singleton when there is more than
> one client in the same process, and they don't know about each other?. What
> I'm potentially trying to avoid is something like:
>
> - Client A initializes the TimeService and starts using it in a realtime
> context.
> - Client B initializes the TimeService (no-op, as A already did this) and
> starts using it in a realtime context.
> - Client A is done and calls TimeService::Release()
> - Client B tries to use the time service and ends up allocating resources
> in a realtime context
>
> What other solutions are there apart from assuming a memory leak or a
> potential mode switch?.
>

Since TimeService is only a few bytes of data, we instantiate it once and
leave it alive during the whole process. Release is only called by the os
stop functions of RTT. So don't call Release in client code.

Peter

Managing TimeService resources

On Thu, May 16, 2013 at 4:58 PM, Peter Soetens <peter [..] ...>wrote:

>
>
> Hi Adolfo,
>
> On Thu, May 16, 2013 at 3:28 PM, Adolfo Rodríguez Tsouroukdissian <
> adolfo [dot] rodriguez [..] ...> wrote:
>
>> Hi,
>>
>> I'm wondering how to properly manage the resources and lifecycle of a
>> RTT::os::TimeService instance. Considering that:
>>
>> - TimeService is a singleton, and resources are dynamically allocated the
>> first time TimeService::Instance() is called.
>>
>> - TimeService::Release() frees currently allocated resources, if any.
>>
>> How can I manage the lifecycle of this singleton when there is more than
>> one client in the same process, and they don't know about each other?. What
>> I'm potentially trying to avoid is something like:
>>
>> - Client A initializes the TimeService and starts using it in a realtime
>> context.
>> - Client B initializes the TimeService (no-op, as A already did this) and
>> starts using it in a realtime context.
>> - Client A is done and calls TimeService::Release()
>> - Client B tries to use the time service and ends up allocating resources
>> in a realtime context
>>
>> What other solutions are there apart from assuming a memory leak or a
>> potential mode switch?.
>>
>
> Since TimeService is only a few bytes of data, we instantiate it once and
> leave it alive during the whole process. Release is only called by the os
> stop functions of RTT. So don't call Release in client code.
>
>
Oh, OK!. So I also don't have to call TimeService::Instance() when setting
up the component to make sure that the first update() does not allocate
resources.

Thanks for the insight,

Adolfo.

Peter
>
>