Path: csiph.com!1.us.feeder.erje.net!feeder.erje.net!1.eu.feeder.erje.net!news.albasani.net!.POSTED!not-for-mail From: j4n bur53 Newsgroups: comp.lang.java.programmer Subject: Re: Library for Escalable Locks, Slimmest API? Date: Sat, 13 Aug 2016 11:37:25 +0200 Organization: albasani.net Lines: 90 Message-ID: References: <26c75c11-5955-45a6-919d-3de1255c9c15@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net JxiFEloX3XNz8GNiESbyNFJDRXcOPm+bUxiCC2VJwyFK+lMsGZAHSfmcRFyo/FvutlhZhLCT/w4RskAbS/tRftqFn8HnarAhNh3A7UFAZpd8BoDmAEAc7r3RxcORI2wa NNTP-Posting-Date: Sat, 13 Aug 2016 09:37:25 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="slRqBXua1tm64YBY4u8haaJkssdaK0lYFuq3uU2T8JZ681lotaigG96rpDic4ue8ylvtp+KnFhcVxizCtkXUWEWz8ZSxmZcZtsDz5VUqqzKa3Oz0+ABvI0WWU2QppkFG"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 In-Reply-To: Cancel-Lock: sha1:gqbtl5D3+C4vlVd/F4H1fTfzp8A= Xref: csiph.com comp.lang.java.programmer:35296 Robert Klemme schrieb: > On 11.08.2016 12:43, Jan Burse wrote: > >> I am planning to open source my new implementation >> of ReadWrite locks, that do escalate.(*) > > But please do it with a big, red warning sign "There may be deadlocks!" > >> Possibly go with the first variant first, until >> it is hardened. > > How do you harden something that inherently comes with the potential for > deadlock? > > Kind regards > > robert > Deadlock-freeness is a property of the application program that uses parallel components and some synchronization primitives. I am not the one who writes the application program, I am only the one who is looking form some synchronization primitives. I am not giving any promises that the synchronization primitives guarantee deadlock-freeness of all application programs. After all this cannot be guranteed. Take for example the ordinary Java monitors, the simple synchronized statement. You can very easily code a deadlock via the following code: Object lock_A Object lock_B Thread thread_A : synchronized (lock_A) { synchronized (lock_B) { } } Thread thread_B : synchronized (lock_B) { synchronized (lock_A) { } } If you read carefully what I wrote, you will see that I am locking for synchronization primitives that time-out. Synchronization primitives that time-out can also not guarantee deadlock-freeness of all application programs. But to some extend, when use with clean exception handling, they can signal deadlocks, without some graph analysis. But it is not guaranteeded that the deadlock is goes away, when the transaction is tryed again. By hardening I mean the synchronization primitives, they might contain programming errors, especially since as of now I didn't find a library and rolled my own. They are already partially open source here: Package Miscellaneous http://www.jekejeke.ch/idatab/doclet/blog/en/docs/05_run/01_kernel/misc/package.jsp See class AbstractLock See class ReadWrite See class ReadLock See class WriteLock The source is incomplete since I have not yet uploaded SetHash. The read and write lock are escalable in the sense that a thread can have a read and a write lock at the same time, but the read and write locks are currently not reentrant, and condition variables are currently also not provided. The application I have in mind, is not yet completely written. I am already using the write locks successfully, but not yet the read locks as planned. Hardenning the application towards deadlock-freeness will make no sense, since we cannot prove deadlock-freeness for the application I have in mind. Bye