Merge pull request #1 from vkuptcov/feature-fix-possible-concurrent-t…

…imer-update

+ use AtomicLong instead a local long as a logical timestamp

.gitignore

@@ -2,3 +2,6 @@
 *.class
 target/
 *~
+build.sbt
+project
+stapl-core.iml

src/main/scala/stapl/core/pdp/TimestampGenerator.scala

@@ -1,5 +1,7 @@
 package stapl.core.pdp
 
+import java.util.concurrent.atomic.AtomicLong
+
 /**
  * Class responsible for generating a globally unique timestamp. These timestamps
  * are longs that have an ascending order. Notice that these timestamps do not
@@ -15,22 +17,19 @@ trait TimestampGenerator {
 }
 
 /**
- * Simple implementation of a timing server: just increment a local variable.
+ * Simple implementation of a timing server.
  * Not a robust implementation for distributed scenarios: it is hard to replace it
  * by another timing server because the count is not known externally.
  */
 class SimpleTimestampGenerator extends TimestampGenerator {
 
- private var counter: Long = 0
+ private val counter = new AtomicLong(0)
 
  /**
  * Simple implementation using an internal counter. This leads to a possible
  * exception in uniqueness in case of long roll-over, but this is assumed to fall
  * outside the expected lifespan of any request that might still be executing system-wide.
  */
- override def getTimestamp(): String = {
- counter = counter + 1
- s"$counter"
- }
+ override def getTimestamp(): String = counter.incrementAndGet().toString
 
 }