Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #35322

Re: Library for Escalable Locks, Slimmest API?

Show key headers only | View raw

On 14.08.2016 11:42, j4n bur53 wrote:
> Robert Klemme schrieb:

Thank you for the following explanations!

>> So are you writing the application or not?
>
> The application I need the locks for is a parallel Prolog
> class loader. This loader will not have any guarantees
> for deadlock-freeness.
>
> If a deadlock happens, one of the threads will time-out
> and the other thread will win. The parallel Prolog class
> loader is already in production for a couple of years.
>
> I am now doing a refinement, the old version was unsing
> a mutex the new version will use read write pairs. The
> refinement has to do with a performance optimization.
>
> The performance optimization is such that Prolog can
> distinguish between static and dynamic predicates. Do
> avoid locks at runtime in static predicates I need a more
> complicated Prolog class loader.
>
> The more complicated Prolog class loader will use read
> locks during predicate lookup, and write locks during
> Prolog text consult. As a new benefit it will not anymore
> happen that predicates see gradually loaded predicates.
>
> Currently it is possible that a thread that does not do
> the loading of the Prolog text, will see how a predicate
> gradually is loaded. The new read lock will prevent this.
>
> On the other hand the thread that does the loading, and
> which has the write lock, should be permitted to also
> read the predicate. This is needed durig loading.

That is possible with a ReadWriteLock: if you hold the write lock the 
resource is yours to write but of course also to read.

> So here in the following is a map what new scenarios are
> needed, and how the different locks support that, and why I
> need new synchronization primitives:
>
> Thread A: Re-Loads Text T
> Thread B1, .. Thread Bn: Executes Text T

This sounds as if there are dedicated threads for loading.  If this is 
the case then acquiring the write lock right away for these would be 
sufficient it seems.

You only then could face starvation issues which you can remedy by using 
fair mode:
http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html

> <>: Atomic
> RW: Ordinary Read Write Lock Pair
> ERW: Escalable Read Write Lock Pair
>
> Situation               Mutex   RW        ERW
> <A_w_T>                 No(1)   Yes       Yes
> <B1_r_T ... Bn_r_T>
>
> <A_w_T A_r_T>           No(1)   No(2)     Yes
> <B1_r_T ... Bn_r_T>
>
> <A_r_T A_w_T>           No(1)   No(2)     Yes
> <B1_r_T ... Bn_r_T>
>
> (1) mutex cannot be used, since mutex does
> not allow multiple readers
> (2) ordinary read write pair cannot be used,
> since ordinary read write pair does not
> allow same thread to be reader and write

In case there are no dedicated loading threads:

If you are trying to optimize this, then a different scheme might work 
as well: you could hold the resource in an AtomicReference.  Whenever a 
thread reads null, it needs to load the resource and update the 
reference.  The object representing the loaded file content then should 
of course be immutable.  Downside is that sometimes multiple threads 
might be reading but you can ensure that only one of them updates the 
reference.

Alternatively the algorithm without any need for lock escalation could 
be like this (pseudo code):

final boolean needsLoading
acquire r-l
needsLoading = resourceNeedsLoading()

if (!needsLoading) {
    useIt()
}
release r-l

if (needsLoading) {
   acquire w-l
   if ( resourceNeedsLoading() ) {
     loadFromFile()
     updateResource()
   }
   release w-l

   acquire rl
   assert !resourceNeedsLoading()
   useIt()
   release rl
}

resourceNeedsLoading() could then either check whether the resource has 
been loaded at all or also include modified time checks on the file.

I do not know though how consistency requirements are in your 
application on a larger scale - especially since you mention 
"re-loading".  Under which circumstances is a file reloaded?

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Library for Escalable Locks, Slimmest API? Jan Burse <janburse@fastmail.fm> - 2016-08-07 18:55 +0200
  Re: Library for Escalable Locks, Slimmest API? Andreas Leitgeb <avl@logic.at> - 2016-08-08 01:10 +0000
    Re: Library for Escalable Locks, Slimmest API? j4n bur53 <janburse@fastmail.fm> - 2016-08-08 09:38 +0200
      Re: Library for Escalable Locks, Slimmest API? j4n bur53 <janburse@fastmail.fm> - 2016-08-08 09:47 +0200
      Re: Library for Escalable Locks, Slimmest API? Andreas Leitgeb <avl@logic.at> - 2016-08-10 14:39 +0000
        Re: Library for Escalable Locks, Slimmest API? Jan Burse <janburse@fastmail.fm> - 2016-08-10 18:05 +0200
          Re: Library for Escalable Locks, Slimmest API? Lew <lewbloch@gmail.com> - 2016-08-10 17:44 -0700
            Re: Library for Escalable Locks, Slimmest API? Jan Burse <janburse@fastmail.fm> - 2016-08-11 12:43 +0200
              Re: Library for Escalable Locks, Slimmest API? Robert Klemme <shortcutter@googlemail.com> - 2016-08-12 22:18 +0200
                Re: Library for Escalable Locks, Slimmest API? Andreas Leitgeb <avl@logic.at> - 2016-08-13 05:56 +0000
                Re: Library for Escalable Locks, Slimmest API? Robert Klemme <shortcutter@googlemail.com> - 2016-08-13 11:08 +0200
                Re: Library for Escalable Locks, Slimmest API? j4n bur53 <janburse@fastmail.fm> - 2016-08-13 11:37 +0200
                Re: Library for Escalable Locks, Slimmest API? j4n bur53 <janburse@fastmail.fm> - 2016-08-13 11:39 +0200
                Re: Library for Escalable Locks, Slimmest API? Jan Burse <janburse@fastmail.fm> - 2016-08-13 12:27 +0200
                Re: Library for Escalable Locks, Slimmest API? Robert Klemme <shortcutter@googlemail.com> - 2016-08-13 23:21 +0200
                Re: Library for Escalable Locks, Slimmest API? j4n bur53 <janburse@fastmail.fm> - 2016-08-14 11:42 +0200
                Re: Library for Escalable Locks, Slimmest API? j4n bur53 <janburse@fastmail.fm> - 2016-08-14 11:50 +0200
                Jumping to false Conclusions [Robert Klemme] (Was: Library for Escalable Locks, Slimmest API?) j4n bur53 <janburse@fastmail.fm> - 2016-08-14 12:06 +0200
                Re: Jumping to false Conclusions [Robert Klemme] (Was: Library for Escalable Locks, Slimmest API?) j4n bur53 <janburse@fastmail.fm> - 2016-08-14 13:08 +0200
                Re: Jumping to false Conclusions [Robert Klemme] (Was: Library for Escalable Locks, Slimmest API?) Robert Klemme <shortcutter@googlemail.com> - 2016-08-14 13:45 +0200
                Re: Jumping to false Conclusions [Robert Klemme] (Was: Library for Escalable Locks, Slimmest API?) j4n bur53 <janburse@fastmail.fm> - 2016-08-14 14:01 +0200
                Re: Jumping to false Conclusions [Robert Klemme] (Was: Library for Escalable Locks, Slimmest API?) j4n bur53 <janburse@fastmail.fm> - 2016-08-14 14:01 +0200
                Re: Jumping to false Conclusions [Robert Klemme] (Was: Library for Escalable Locks, Slimmest API?) j4n bur53 <janburse@fastmail.fm> - 2016-08-14 14:07 +0200
                Re: Library for Escalable Locks, Slimmest API? Robert Klemme <shortcutter@googlemail.com> - 2016-08-14 12:13 +0200
                Re: Library for Escalable Locks, Slimmest API? j4n bur53 <janburse@fastmail.fm> - 2016-08-14 12:25 +0200
                Re: Library for Escalable Locks, Slimmest API? j4n bur53 <janburse@fastmail.fm> - 2016-08-14 12:36 +0200
                Re: Library for Escalable Locks, Slimmest API? Robert Klemme <shortcutter@googlemail.com> - 2016-08-14 13:41 +0200
                Re: Library for Escalable Locks, Slimmest API? j4n bur53 <janburse@fastmail.fm> - 2016-08-14 12:45 +0200
                Re: Library for Escalable Locks, Slimmest API? j4n bur53 <janburse@fastmail.fm> - 2016-08-14 12:49 +0200
                Re: Library for Escalable Locks, Slimmest API? j4n bur53 <janburse@fastmail.fm> - 2016-08-14 13:45 +0200
                Re: Library for Escalable Locks, Slimmest API? j4n bur53 <janburse@fastmail.fm> - 2016-08-14 13:48 +0200
                Re: Library for Escalable Locks, Slimmest API? Robert Klemme <shortcutter@googlemail.com> - 2016-08-14 14:29 +0200
                Re: Library for Escalable Locks, Slimmest API? j4n bur53 <janburse@fastmail.fm> - 2016-08-14 14:56 +0200
                Re: Library for Escalable Locks, Slimmest API? j4n bur53 <janburse@fastmail.fm> - 2016-08-14 14:59 +0200
                Re: Library for Escalable Locks, Slimmest API? Jan Burse <janburse@fastmail.fm> - 2016-08-14 18:10 +0200
  Simpler requirements on the horizon! (Re: Library for Escalable Locks, Slimmest API?) j4n bur53 <janburse@fastmail.fm> - 2016-08-14 13:18 +0200
  I dont see a deadlock (Re: Library for Escalable Locks, Slimmest API?) j4n bur53 <janburse@fastmail.fm> - 2016-08-31 01:23 +0200
    Re: I dont see a deadlock (Re: Library for Escalable Locks, Slimmest API?) bursejan@gmail.com - 2016-08-30 16:35 -0700
      Re: I dont see a deadlock (Re: Library for Escalable Locks, Slimmest API?) bursejan@gmail.com - 2016-08-30 16:45 -0700
        Re: I dont see a deadlock (Re: Library for Escalable Locks, Slimmest API?) Andreas Leitgeb <avl@logic.at> - 2016-08-31 09:23 +0000
          Re: I dont see a deadlock (Re: Library for Escalable Locks, Slimmest API?) Andreas Leitgeb <avl@logic.at> - 2016-08-31 10:13 +0000
          Re: I dont see a deadlock (Re: Library for Escalable Locks, Slimmest API?) j4n bur53 <janburse@fastmail.fm> - 2016-08-31 14:00 +0200
        Re: I dont see a deadlock (Re: Library for Escalable Locks, Slimmest API?) Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-08-31 07:49 -0400
          Re: I dont see a deadlock (Re: Library for Escalable Locks, Slimmest API?) j4n bur53 <janburse@fastmail.fm> - 2016-08-31 14:13 +0200
            Re: I dont see a deadlock (Re: Library for Escalable Locks, Slimmest API?) Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-08-31 12:55 -0400
    Re: I dont see a deadlock (Re: Library for Escalable Locks, Slimmest API?) Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-08-31 07:54 -0400

csiph-web