Re: [osgi-dev] Question about consistency and visibility

[Tim Ward via osgi-dev]

> DS guarantees that activate is called before the service is registered and 
> thus available to others.

This is not quite correct (although it is correct for immediate components). 
The service is registered after it becomes satisfied (all of its mandatory 
service and configuration dependencies are available) but before it is 
activated. This is because DS is lazy, and won’t instantiate/activate a 
component until it is needed. Therefore your activate method is not called 
until someone tries to get your component’s service, at which point the 
activate method is called and run to successful completion before the service 
is given to the requesting bundle.

You can rely on the activate method having successfully completed before the 
instance is available to any other bundle. This is the important part of the 
guarantee from a happens before perspective, and is the reason that using a 
static policy is both simple and thread safe. Obviously if your component is 
immediate then it will be activated as soon as it is satisfied. If the 
immediate component advertises a service then nobody will be able to access the 
instance until after the activate method returns.

Best Regards,

Tim

> On 14 Aug 2018, at 07:33, Peter Kriens via osgi-dev  
> wrote:
> 
> Your understanding is correct with respect to the _service_. DS guarantees 
> that activate is called before the service is registered and thus available 
> to others.  The service is unregistered before you deactivate is called. 
> Nulling fields is generally unnecessary unless you want to ensure an NPE if 
> an object uses your service after unregistering.
> 
> Kind regards,
> 
>   Peter Kriens
> 
>> On 14 Aug 2018, at 05:20, David Leangen via osgi-dev > > wrote:
>> 
>> 
>> Hi!
>> 
>> In a concurrent system, if a class is immutable, the problem is simplified 
>> and the class can be used without fear by multiple threads because (i) it’s 
>> state does not change, and (2) it’s state is guaranteed to be visible;
>> 
>> Example:
>> 
>> /**
>>  * The class is immutable because the fields are both immutable types
>>  * and are "private + final”. The fields are guaranteed to be visible
>>  * to all threads after construction. In other words, there is a
>>  * “happens-before” constraint on the fields.
>>  */
>> public class SimpleImmutableClass {
>> private final String value1;
>> private final int value2;
>> 
>> public SimpleImmutableClass( String aString, int anInt ) {
>> value1 = aString;
>> value2 = anInt;
>> }
>> 
>> public String getValue1() {
>> return value1;
>> }
>> 
>> public int getvalue2() {
>> return value2;
>> }
>> }
>> 
>> My understanding is that DS will provide the same happens-before constraint 
>> to the fields in the following service, so presuming that there is no method 
>> exposed to change the field values, the service is effectively immutable and 
>> can be used without fear in a concurrent context. So in the following, 
>> value1 and value2 are guaranteed to be visible to all threads thanks to the 
>> happens-before constraint placed on the fields during activation:
>> 
>> /**
>>  * The LogService is basically just added to show that the component is used
>>  * in a static way, as only a static component can be effectively immutable.
>>  */
>> @Component
>> public class EffectivelyImmutableService {
>> private String value1;
>> private int value2;
>> 
>> @Reference private LogService logger;
>> 
>> @Activate
>> void activate( Map properties ) {
>> value1 = (String)properties.get( "value1" );
>> value2 = (int)properties.get( "value2" );
>> }
>> 
>> /**
>>  * H, but if an instance is never reused, then wouldn't it be 
>> completely
>>  * unnecessary to deactivate()??
>>  */
>> void deactivate() {
>> value1 = null;
>> value2 = -1;
>> }
>> 
>> public String getValue1() {
>> logger.log( LogService.LOG_INFO, String.format( "Value of String is 
>> %s", value1 ) );
>> return value1;
>> }
>> 
>> public int getvalue2() {
>> logger.log( LogService.LOG_INFO, String.format( "Value of int is 
>> %s", value2 ) );
>> return value2;
>> }
>> }
>> 
>> 
>> Is somebody able to confirm my understanding?
>> 
>> Thanks!!
>> =David
>> 
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org 
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Question about consistency and visibility

[Peter Kriens via osgi-dev]

Your understanding is correct with respect to the _service_. DS guarantees that 
activate is called before the service is registered and thus available to 
others.  The service is unregistered before you deactivate is called. Nulling 
fields is generally unnecessary unless you want to ensure an NPE if an object 
uses your service after unregistering.

Kind regards,

Peter Kriens

> On 14 Aug 2018, at 05:20, David Leangen via osgi-dev  
> wrote:
> 
> 
> Hi!
> 
> In a concurrent system, if a class is immutable, the problem is simplified 
> and the class can be used without fear by multiple threads because (i) it’s 
> state does not change, and (2) it’s state is guaranteed to be visible;
> 
> Example:
> 
> /**
>  * The class is immutable because the fields are both immutable types
>  * and are "private + final”. The fields are guaranteed to be visible
>  * to all threads after construction. In other words, there is a
>  * “happens-before” constraint on the fields.
>  */
> public class SimpleImmutableClass {
> private final String value1;
> private final int value2;
> 
> public SimpleImmutableClass( String aString, int anInt ) {
> value1 = aString;
> value2 = anInt;
> }
> 
> public String getValue1() {
> return value1;
> }
> 
> public int getvalue2() {
> return value2;
> }
> }
> 
> My understanding is that DS will provide the same happens-before constraint 
> to the fields in the following service, so presuming that there is no method 
> exposed to change the field values, the service is effectively immutable and 
> can be used without fear in a concurrent context. So in the following, value1 
> and value2 are guaranteed to be visible to all threads thanks to the 
> happens-before constraint placed on the fields during activation:
> 
> /**
>  * The LogService is basically just added to show that the component is used
>  * in a static way, as only a static component can be effectively immutable.
>  */
> @Component
> public class EffectivelyImmutableService {
> private String value1;
> private int value2;
> 
> @Reference private LogService logger;
> 
> @Activate
> void activate( Map properties ) {
> value1 = (String)properties.get( "value1" );
> value2 = (int)properties.get( "value2" );
> }
> 
> /**
>  * H, but if an instance is never reused, then wouldn't it be 
> completely
>  * unnecessary to deactivate()??
>  */
> void deactivate() {
> value1 = null;
> value2 = -1;
> }
> 
> public String getValue1() {
> logger.log( LogService.LOG_INFO, String.format( "Value of String is 
> %s", value1 ) );
> return value1;
> }
> 
> public int getvalue2() {
> logger.log( LogService.LOG_INFO, String.format( "Value of int is %s", 
> value2 ) );
> return value2;
> }
> }
> 
> 
> Is somebody able to confirm my understanding?
> 
> Thanks!!
> =David
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



smime.p7s
Description: S/MIME cryptographic signature
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] Question about consistency and visibility

[David Leangen via osgi-dev]

Hi!

In a concurrent system, if a class is immutable, the problem is simplified and 
the class can be used without fear by multiple threads because (i) it’s state 
does not change, and (2) it’s state is guaranteed to be visible;

Example:

/**
 * The class is immutable because the fields are both immutable types
 * and are "private + final”. The fields are guaranteed to be visible
 * to all threads after construction. In other words, there is a
 * “happens-before” constraint on the fields.
 */
public class SimpleImmutableClass {
private final String value1;
private final int value2;

public SimpleImmutableClass( String aString, int anInt ) {
value1 = aString;
value2 = anInt;
}

public String getValue1() {
return value1;
}

public int getvalue2() {
return value2;
}
}

My understanding is that DS will provide the same happens-before constraint to 
the fields in the following service, so presuming that there is no method 
exposed to change the field values, the service is effectively immutable and 
can be used without fear in a concurrent context. So in the following, value1 
and value2 are guaranteed to be visible to all threads thanks to the 
happens-before constraint placed on the fields during activation:

/**
 * The LogService is basically just added to show that the component is used
 * in a static way, as only a static component can be effectively immutable.
 */
@Component
public class EffectivelyImmutableService {
private String value1;
private int value2;

@Reference private LogService logger;

@Activate
void activate( Map properties ) {
value1 = (String)properties.get( "value1" );
value2 = (int)properties.get( "value2" );
}

/**
 * H, but if an instance is never reused, then wouldn't it be completely
 * unnecessary to deactivate()??
 */
void deactivate() {
value1 = null;
value2 = -1;
}

public String getValue1() {
logger.log( LogService.LOG_INFO, String.format( "Value of String is 
%s", value1 ) );
return value1;
}

public int getvalue2() {
logger.log( LogService.LOG_INFO, String.format( "Value of int is %s", 
value2 ) );
return value2;
}
}


Is somebody able to confirm my understanding?

Thanks!!
=David

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev