aboutsummaryrefslogtreecommitdiffstats
path: root/src/java/jogamp/common/util
Commit message (Collapse)AuthorAgeFilesLines
* Bug 1213: Use InterruptSource.ThreadSven Gothel2015-09-152-3/+5
|
* Bug 1213: Refine changes .. comments and APISven Gothel2015-09-152-50/+80
| | | | | | | | | | | | | | - Use InterruptSource.Thread.create(..), while reducing InterruptSource.Thread ctors to 3 variants. - Use InterruptSource.Thread instead of java.lang.Thread where possible - Use SourcedInterruptedException where possible - SingletonInstanceServerSocket: start(), stop() and run() - Persistent-Wait and Cancelable - Add @since 2.3.2
* Bug 1213 - RecursiveThreadGroupLockImpl01Unfairish.unlock() always ↵Sven Gothel2015-09-052-8/+23
| | | | | | | | | | | | | | | | | | | | | | | interrupts original-owner, even if not waiting at unlock() RecursiveThreadGroupLockImpl01Unfairish.unlock(): An interrupt() is always issued from group members on the original owner. This shall only happen, if the original owner is waiting within unlock() for all group members to be unlocked. This extra interrupt causes side-effects, see Bug 1211. Only issue the interrupt to wake-up the original owner iff waiting within unlock! +++ RecursiveLockImpl01CompleteFair: Issue 'Thread.interrupted()' to clear a slipped interrupt call after while-loop.
* RecursiveThreadGroupLockImpl01Unfairish: Add toString() in ↵Sven Gothel2015-08-291-2/+2
| | | | IllegalArgumentException exceptions
* Fix Bitfield.put(..): Return previous valueSven Gothel2015-08-023-12/+20
|
* SyncedBitfield.clearField: Must be synchronizedSven Gothel2015-08-021-1/+1
|
* Bitfield: Refine API method names, add clearField(boolean), fix put32(..) ↵Sven Gothel2015-08-023-24/+51
| | | | and bitCount(), add unit test (passed)
* Bitfield: Refine impl. complete get/put 32bit, add copy*(..), add ↵Sven Gothel2015-07-313-44/+232
| | | | synchronized delegation; TODO: Unit tests.
* Bitfield: Use IndexOutOfBoundsException instead of ↵Sven Gothel2015-07-302-16/+16
| | | | ArrayIndexOutOfBoundsException
* Introduce Bitfield interface w/ Int32 and Int32Array impl. deprecating ↵Sven Gothel2015-07-302-0/+243
| | | | | | | | | | | | | IntBitfield IntBitfield's 64bit bit-size is exceeding its use-case, making it less efficient and complicated. Bitfield offers a fast path implementation for 32 bits as well as a int[] implementation. TODO: 32 bit Unaligned putInt32(..) and getInt32(..), currently throwing UnsupportedOperationException for int[] impl.
* Code Clean-Up based on our Recommended Settings (jogamp-scripting ↵Sven Gothel2014-07-037-69/+69
| | | | | | | | | | | | | | | c47bc86ae2ee268a1f38c5580d11f93d7f8d6e74) Code Clean-Up based on our Recommended Settings (jogamp-scripting c47bc86ae2ee268a1f38c5580d11f93d7f8d6e74) - Change non static accesses to static members using declaring type - Change indirect accesses to static members to direct accesses (accesses through subtypes) - Add final modifier to private fields - Add final modifier to method parameters - Add final modifier to local variables - Remove unnecessary casts - Remove unnecessary '$NON-NLS$' tags - Remove trailing white spaces on all lines
* gluegen: remove trailing whitespaceHarvey Harrison2013-10-177-137/+137
| | | | Signed-off-by: Harvey Harrison <[email protected]>
* Fix SingletonInstanceServerSocket.kill(): Needs to mark alive=false in case ↵Sven Gothel2013-06-251-1/+1
| | | | of JVM shutdown!
* RecursiveThreadGroupLockImpl01Unfairish: Fix DEBUG outputSven Gothel2013-05-051-3/+4
|
* Fix RecursiveLockImpl* corner case: Timeout reached but lock released -> ↵Sven Gothel2013-03-182-16/+20
| | | | | | Assume Lock If timeout has been reached but the lock has been released, the lock has to be assumed.
* gluegen: replace Thread name with name of lock file in ↵Harvey Harrison2012-10-161-1/+1
| | | | | | | | | | | | SingletonInstanceFileLock error message The getName() call here is currently calling Thread.getName() inherited by the anonymous inner class. This is ambiguous, and likely meant to call the getName() method of SingletonInstanceFileLock, which would output the lockfile name. In any event, infoPrefix() is already adding the Thread name for us. Signed-off-by: Harvey Harrison <[email protected]>
* SingletonInstanceServerSocket: serverSocket.setReuseAddress(true); // reuse ↵Sven Gothel2012-10-041-0/+1
| | | | same port w/ subsequent instance, i.e. overcome TO state when JVM crashed
* SingletonInstanceServerSocket: Add unit tests; Create new server Thread @ ↵Sven Gothel2012-09-212-18/+18
| | | | start, otherwise we may collide w/ a failed start. Misc: Cleanup / reuse strings.
* SingletonInstanceServerSocket: Add kill @ JVM Shutdown _and_ if normal ↵Sven Gothel2012-09-212-8/+42
| | | | unlock fails ; Added unit tests.
* Lock Cleanup (API Change)Sven Gothel2012-06-276-17/+64
| | | | | | | | - LockExt -> ThreadLock - clarifying semantics (API Change) - ThreadLock: Remove isOwner(), use isOwner(Thread.currentThread) - adding @Override
* StringBuffer -> StringBuilder (Local objects, no concurrency)Sven Gothel2012-04-161-1/+1
|
* RecursiveThreadGroupLock: New recursive lock interface and impl, allowing ↵Sven Gothel2011-12-111-0/+211
| | | | | | | | | | | | 'spawn off' process to become the lock owner. To avoid complicated synchronization via synchronized, wait and notify between one thread and a 'spawn' off thread which temporarly requires the hold lock, RecursiveThreadGroupLock allows to add and remove other threads to become owners of the lock as if they were the original holder. This simplifies some rare locking use cases, eg. in JOGL's GLProfile initialization sequence where a SharedResourceRunner thread is taking over initialization of shared resources.
* Cleanup Lock Package: API doc, complete throws declaration, interface ↵Sven Gothel2011-12-113-43/+83
| | | | | | RecursiveLockImpl01Unfairish.Sync RecursiveLockImpl01Unfairish changes are in preparation of RecursiveGroupThreadLock.
* Lock ChangeSet (fin): Cleanup, fix and enhance RecursiveLock implementationSven Gothel2011-09-274-122/+613
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - RecursiveLock _is_ interface. - Use LockFactory to create a RecursiveLock. - Impl: RecursiveLockImpl01Unfairish - just using notify w/o any queue: fast - still enqueuing new lock-applicants if queue full (nice) - lock's sync extends AbstractOwnableSynchronizer and uses it (monitor) - Impl: RecursiveLockImpl01CompleteFair - using queue and interrupt for correctness (slow) - lock's sync extends AbstractOwnableSynchronizer and uses it (monitor) - Impl: RecursiveLockImplJava5 for using Java5's concurrency impl. - to verify correctness, performance and deviation of locking time TestRecursiveLock01 new performance measurements incl. simple avrg and deviation shows best combined performance-deviation w/ our RecursiveLockImpl01Unfairish os Linux and MacOSX. RecursiveLockImpl01Unfairish is the default in LockFactory. Adding 'private' LockDebugUtil, allowing validating all holdings locks of one thread as stack traces (Throwable). Besides the AbstractOwnableSynchronizer utilization, this helps debugging deadlocks and starvation very well.
* Lock ChangeSet: Prepare RecursiveLock to be an implementation of it's new ↵Sven Gothel2011-09-271-0/+245
| | | | interface
* SingletonInstanceServerSocket: composite thread name w/ leading original oneSven Gothel2011-09-251-1/+8
|
* SingletonInstanceServerSocket: Fix setDaemon(true), give Thread a proper nameSven Gothel2011-06-121-2/+2
|
* SingletonInstance Enhancements / Minor Lock/LockExt API Change (isLocked ↵Sven Gothel2011-06-112-0/+351
moved up) We learned that FileChannel.lock() is not reliable on at least GNU/Linux + Sun's JVM implementation, hence we need a ServerSocket implementation. Since this code may be useful to others, it has been promoted to GlueGen. - Abstract SingletonInstance - Implement Lock interface - SingletonInstance Spezialisation: FileLock and ServerSocket Minor API Change: LockExt.isLocked() -> Lock.isLocked()
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-11 20:32:37 +0000