More specifically, when called twice on the same thread, the second call will never return a value that is less then the value returned by the first call. If a system time correction becomes necessary, an attempt will be made to gradually compensate the returned value, so in the long run the value returned by this method is the same as the system time.

The standard naming convention for system properties is '.' Separated property names, such as "tangosol.coherence.setting".

As of Coherence 3.4 the only source for system properties is environment variables. As some environemts do not allow '.' in variable names, a failed lookup will be automatically re-issued using a camel-cased version of the supplied name, i.e. the property name "tangosol.coherence.setting" would translated to "TangosolCoherenceSetting". From a code level perspective camel-case does not need to be a consideration, it is only when setting environment variables that it may be needed.

Parameters:

vsName

the name of the property to return

vsDefault

the default value for the property

Returns:

the corresponding property value, or the supplied default if no value could be found

Return the same hash code for the given object as would be returned by the default implementation provided in Object.

In the case of NULL zero is returned.

Parameters:

v

the object to hash

Returns:

the object's identity hash code.

static void setInterruptResolution

(

int64_t

cMillis

)

[static]

Specify the system interrupt resolution.

The resolution at which a blocked thread will test if it has been interrupted. Not all blocking states are guaranteed to utilize this feature, but at a minimum Object::wait(), and Coherence based network communications do respect this setting.

Once in a blocking state the blocked call may not see updates to this setting. If this setting is to be updated it is recommended that it only occur once at application startup.

Recommended values are between 100 and 1000 milliseconds, default is 250 milliseconds.

Return the common monitor associated with the specified integer value.

Common monitors allow for a low-cost means to reduce contention by spreading synchronization over a large number of monitors. An example usage would be to produce an "atomic array". For instance to atomically change an element within an array which is being simultaneously updated by multiple threads:

With this approach many threads may concurrently access various array elements without having to synchronize on the array itself, and contend with each other. The use of common monitors also avoids the overhead of allocating a unique monitor per index. This example additionally makes use of the array's identity hash code to avoid frequent collisions against other atomic arrays for the same indices.

As they are shared, these monitors will apply to any number of unrelated entities, and as such certain precautions must be employed when using them.

The holder of a common monitor MUST not synchronize on any other common monitor. Failure to adhere to this precaution will result in a deadlock.

Notifications on a common monitor MUST use notifyAll() rather then notify(), as there may be unrelated threads waiting for notification on the same monitor which could consume a single notification. Thus the only way to ensure that the desired thread does receive notification is to notify all threads waiting on the monitor.

Threads waiting for a notification must protect themselves against spurious style wakeups. While this is a general, though often overlooked part of the normal use of notification, with common monitors it is far more likely that a thread will be notified due to an unrelated event.

A thread which is holding synchronization on a common monitor should avoid blocking operations as this could block unrelated threads which happen to be utilizing the same common monitor.

The ideal number of common monitors in a process is one per concurrently executing thread. As this number is generally unknown the default number of monitors set to a relatively high value. The value may also be manually specified via the tangosol.coherence.commonmonitors system property.