Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

A method to effect contextual event based- keywords/access modifiers in managed runtimes

IP.com Disclosure Number: IPCOM000210045D
Publication Date: 2011-Aug-23
Document File: 8 page(s) / 51K

Publishing Venue

The IP.com Prior Art Database


In statically typed languages 'modifier keywords' are typically effected on a data or a function for it's complete lifetime. There are scenarios where the scope of data or a function needs to be altered or reverted, hence a method is proposed to effect a flexibility in the assignment of a certain keyword by providing the ability to confine it to a certain user defined context

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 29% of the total text.

Page 01 of 8

A method to effect contextual event based - keywords/access modifiers in managed runtimes

In a statically-typed language, 'modifier keywords' are used to specify the action and scope on the corresponding data type during execution time. These keywords are processed during compile time and corresponding intermediate representation or executable is generated to be run by the run-time engine.

The functionality of certain keywords may be not be necessary for the whole lifetime of the program. Consider the scenarios below:

Usecase 1: (Synchronized)

Singleton patterns are used in designs where a single object is required to coordinate actions across the system. The below code snippet illustrates the usage of a singleton pattern:

1. // singleton pattern

2. class illustrate {

3. private static Single single = null;


5. public static synchronized Single getSingle() {

6. if (single == null)

7. single = new Single();

8. return single;

9. }

10. }

Thesynchronized keyword ensures that only one thread is able to access the method at any

given time - the lock acquire is necessary to avoid creating multiple objects of theSingle class and to get a consistent view of thesingle variable by all threads.

Although locking is necessary for the population of thesingle variable, it becomes an unnecessary overhead once the initialization is complete .

In this example the functionality of synchronization is required only till the object is populated for the first time and becomes an overhead after that.

Context In Which Synchronization is Required : First population of Variable


Page 02 of 8

Usecase 2: (Volatile)

The synchronization overhead evident in the singleton pattern is overcome by the use of the Double checked locking design pattern.

The below code snippet illustrates the usage of a singleton with a double-checked locking pattern:

1. // double-checked locking pattern

2. class illustrate {

3. private volatile Single single = null;


5. public static Single getSingle() {

6. if (single == null) {

7. synchronized(this) {

8. if (single == null)

9. single = new Single();

10. }

11. }

12. return single;

13. }

14. }

The double-checked locking design pattern requires the threads to get the most recent view of thesingle variable each time it is accessed - the threads must read-in/write-to the variable from/to the main memory. Hence the variable must be declared as "volatile".

Although this avoids locking after the variable is initialized, accessing the variable each time involves reading from the main memory - invalidating and updating of the caches which can be a runtime overhead as stated below :

"The use of volatile is sometimes counter productive since every reference of it (read/write)

 would invalidate the cache line to maintain cache coherence. Sometimes it's better to just use a synchronized block, which invalidates the cache line at the end of the block as part of the memory barrier operation" - http://en.wikipedia.org/wiki/Double-checked_locking.