This adds a P/V style semaphore mechanism to the resource graph. This enables the user to specify a number of "id:count" tags associated with each resource which will reduce the parallelism of the CheckApply operation to that maximum count. This is particularly interesting because (assuming I'm not mistaken) the implementation is dead-lock free assuming that no individual resource permanently ever blocks during execution! I don't have a formal proof of this, but I was able to convince myself on paper that it was the case. An actual proof that N P/V counting semaphores in a DAG won't ever dead-lock would be particularly welcome! Hint: the trick is to acquire them in alphabetical order while respecting the DAG flow. Disclaimer, this assumes that the lock count is always > 0 of course.
78 lines
2.2 KiB
Go
78 lines
2.2 KiB
Go
// Mgmt
|
|
// Copyright (C) 2013-2017+ James Shubin and the project contributors
|
|
// Written by James Shubin <james@shubin.ca> and the project contributors
|
|
//
|
|
// This program is free software: you can redistribute it and/or modify
|
|
// it under the terms of the GNU Affero General Public License as published by
|
|
// the Free Software Foundation, either version 3 of the License, or
|
|
// (at your option) any later version.
|
|
//
|
|
// This program is distributed in the hope that it will be useful,
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
// GNU Affero General Public License for more details.
|
|
//
|
|
// You should have received a copy of the GNU Affero General Public License
|
|
// along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
// Package semaphore contains an implementation of a counting semaphore.
|
|
package semaphore
|
|
|
|
import (
|
|
"fmt"
|
|
)
|
|
|
|
// Semaphore is a counting semaphore. It must be initialized before use.
|
|
type Semaphore struct {
|
|
C chan struct{}
|
|
closed chan struct{}
|
|
}
|
|
|
|
// NewSemaphore creates a new semaphore.
|
|
func NewSemaphore(size int) *Semaphore {
|
|
obj := &Semaphore{}
|
|
obj.Init(size)
|
|
return obj
|
|
}
|
|
|
|
// Init initializes the semaphore.
|
|
func (obj *Semaphore) Init(size int) {
|
|
obj.C = make(chan struct{}, size)
|
|
obj.closed = make(chan struct{})
|
|
}
|
|
|
|
// Close shuts down the semaphore and releases all the locks.
|
|
func (obj *Semaphore) Close() {
|
|
// TODO: we could return an error if any semaphores were killed, but
|
|
// it's not particularly useful to know that for this application...
|
|
close(obj.closed)
|
|
}
|
|
|
|
// P acquires n resources.
|
|
func (obj *Semaphore) P(n int) error {
|
|
for i := 0; i < n; i++ {
|
|
select {
|
|
case obj.C <- struct{}{}: // acquire one
|
|
case <-obj.closed: // exit signal
|
|
return fmt.Errorf("closed")
|
|
}
|
|
}
|
|
return nil
|
|
}
|
|
|
|
// V releases n resources.
|
|
func (obj *Semaphore) V(n int) error {
|
|
for i := 0; i < n; i++ {
|
|
select {
|
|
case <-obj.C: // release one
|
|
// TODO: is the closed signal needed if unlocks should always pass?
|
|
case <-obj.closed: // exit signal
|
|
return fmt.Errorf("closed")
|
|
// TODO: is it true you shouldn't call a release before a lock?
|
|
default: // trying to release something that isn't locked
|
|
panic("semaphore: V > P")
|
|
}
|
|
}
|
|
return nil
|
|
}
|