vvraskin commented on a change in pull request #3240: Add a loadbalancer with 
local state and horizontal invoker sharding.
URL: 
https://github.com/apache/incubator-openwhisk/pull/3240#discussion_r167266067
 
 

 ##########
 File path: common/scala/src/main/scala/whisk/common/ForcableSemaphore.scala
 ##########
 @@ -0,0 +1,116 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *     http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package whisk.common
+
+import java.util.concurrent.locks.AbstractQueuedSynchronizer
+
+import scala.annotation.tailrec
+
+/**
+ * A Semaphore, which in addition to the usual features has means to force 
more clients to get permits.
+ *
+ * Like any usual Semaphore, this implementation will give away at most 
`maxAllowed` permits when used the "usual" way.
+ * In addition to that, it also has a `forceAcquire` method which will push 
the Semaphore's remaining permits into a
+ * negative value. Getting permits using `tryAcquire` will only be possible 
once the permits value is in a positive
+ * state again.
+ *
+ * As this is (now) only used for the loadbalancer's scheduling, this does not 
implement the "whole" Java Semaphore's
+ * interface but only the methods needed.
+ *
+ * @param maxAllowed maximum number of permits given away by `tryAcquire`
+ */
+class ForcableSemaphore(maxAllowed: Int) {
+  class Sync extends AbstractQueuedSynchronizer {
+    setState(maxAllowed)
+
+    def permits: Int = getState
+
+    @tailrec
+    override final def tryReleaseShared(releases: Int): Boolean = {
+      val current = getState
+      val next = current + releases
+      if (next < current) { // overflow
+        throw new Error("Maximum permit count exceeded")
+      }
+      if (compareAndSetState(current, next)) {
+        true
+      } else {
+        tryReleaseShared(releases)
+      }
+    }
+
+    @tailrec
+    final def nonFairTryAcquireShared(acquires: Int): Int = {
+      val available = getState
+      val remaining = available - acquires
+      if (remaining < 0 || compareAndSetState(available, remaining)) {
 
 Review comment:
   I think it would make sense to split this condition and add a nested _if_ 
for `compareAndSetState(available, remaining))`.
   Given that we have 4 acquires available,say we ask for 5, given that there 
was no concurrent write it will update the state and return the `remaining` 
which is -1. It could cause to deadlock when no releases would follow, what do 
you think?

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to