I would like to update the value vold of a TrieMap t for some key k iff the new value vnew some predicate p(vold, vnew) is true. Since values can be modified through multiple threads, a synchronized block is needed. The code could t.synchronized but that would block updates to other keys' values. Is it possible to block only for the key that's actually being updated?
Now that I've written out the question, does it make sense to t.keySet.filter(_ == k).head.synchronized (since there's no guarantee that k is the same instance of the key in t)? Is there a more canonical way to do this?
Since values can be modified through multiple threads, a synchronized block is needed.
The canonical way of working with TrieMap is to use the replace/putIfAbsent/remove methods. Get the old value, calculate the new value, and if replace fails, repeat.
Looking through the API, I don't see anything suitable to do what you want directly, and t.keySet.filter(_ == k) has to iterate through the entire Map; in most cases I'd expect it to be worse than just locking it (unless you have a lot more threads than entries?).
If p satisfied the following conditions:
antisymmetry (ie p(v0, v1) implies !p(v1, v0) and !p(v0, v1) implies p(v1, v0))
transitivity (ie p(v0, v1) and p(v1, v2) implies p(v0, v1)
The following can be implemented (WARNING: the code below is untested):
def replaceIf(key: K, newvalue: V)(predicate: (V, V) => Boolean): Option[V] = {
val oldvalue = replace(key, newvalue)
if (oldvalue == None || predicate(newvalue, oldvalue.get)) {
oldvalue
} else {
replaceIf(key, oldvalue.get)(predicate)
}
}
Related
Is there a way to "apply" null safety to a multiple assignment from a null? For example, this piece of code would obviously throw:
// verbosity is for clarity
def (a,b) = new HashMap<String, List<String>>().get("nothing")
but it would be neat to have it define a and b with null value.
So far I came up with
def (a,b) = new HashMap<String, List<String>>().get("nothing").with {[it?.get(0), it?.get(1)]}
But that's really ugly...
This is the safe bet, if you have both missing keys and null values:
def (a,b) = new HashMap<String, List<String>>().get("nothing") ?: []
The next one is from Groovy, but modifies the underlying map (so only
works for mutable maps and whether you are fine with modifying it) and
it only gives the default for missing keys:
def (a,b) = new HashMap<String, List<String>>().get("nothing", [])
Similar (also from Groovy and also modifying the underlying map):
withDefault. This option is great if you plan to pass the map around
to other places, that would have to deal with the default all over again
(also only defaults for missing keys):
def (a,b) = new HashMap<String, List<String>>().withDefault{[]}.get("nothing")
And the next one is from Java, but that also only falls back, if the key
is missing:
def (a,b) = new HashMap<String, List<String>>().getOrDefault("nothing",[])
I have a question about using the new Objects.compare(o1, o2, Comparator) method - from my own testing of it, if both o1 and o2 are null then it returns 0, however, if one of them is null then it still throws a null pointer exception. I have found a lot of material on Objects.equals and some of the other Objects utility methods but not much at all on Objects.compare and when we are expected to use it / replace old code with it.
So here I could do this:
String s1 = "hi";
String s2 = "hi";
int x = Objects.compare(s1, s2, Comparator.naturalOrder());
System.out.println("x = " + x);
That works fine, returns 0, now this:
String s1 = null;
String s2 = null;
Also works fine and returns 0. However, this:
String s1 = "hi";
Strng s2 = null;
Throws a NullPointerException. I'm guessing the benefit of Objects.compare(o1,o2,Comparator) vs o1.compareTo(o2) is that it at least handles circumstances where both objects are null and when one of them is null it allows you to design a Comparator to handle it. I'm supposing, e.g.
int x = Objects.compare(s1, s2, Comparator.nullsFirst(Comparator.naturalOrder()));
Whereas with x.compareTo(y) there's no way to handle null unless you do so beforehand? So do the Java library developers now intend us to replace all calls to compareTo with Objects.compare, when we're concerned about nulls? e.g. would we do this in our Comparable implementations?
Side query 1: With regards to using nullsFirst if you use it then pass in a Comparator, which is chained using comparing, thenComparing, etc, does it apply to all of the inner comparators? e.g.
Comparator.nullsFirst(Comparator.comparing(Song::getTitle)
.thenComparing(Song::getArtist)
.thenComparing(Song::getDuration)
)
Would that apply nullsFirst to everything inside or do you need to use nullsFirst individually on each of them? I think from testing that it only applies to the actual Song objects being null, not for the fields of title or artist being null, i.e. if they are null then a NullPointerException is still thrown. Anyway around that?
Side query 2: final question is that because I like the Comparator.comparing syntax, I'm proposing to start to write my compareTo implementions using it - I was struggling to think how to replace this traditional approach, e.g.
public int compareTo(Song other) {
int result = this.title.compareTo(other.title);
if (result == 0) {
result = this.artist.compareTo(other.artist);
if (result == 0) {
result = Integer.compare(this.duration, other.duration);
}
}
return result;
}
then I thought I could use Objects.compare(...) as follows:
public int compareTo(Song other) {
return Objects.compare(this, other, Comparator.nullsFirst(
Comparator.comparing(Song::getTitle)
.thenComparing(Song::getArtist)
.thenComparingInt(Song::getDuration)
));
}
I thought this version was more elegant - I am assuming it is working as I think it is, e.g. by passing this and other as the first 2 arguments then the comparator, it has the same effect as the traditional compareTo approach with if statements? Whilst I can see that the benefit of Objects.compare catching two nulls would never occur as if this was null then the compareTo method call would never be reached (either by handling the exception or it being thrown). But by using nullsFirst I suppose if the argument passed in, i.e. other, was null, then this would handle this safely?
Many thanks in advance for any help.
Objects.compare is not meant to provide a null safe comparison, since there is no default behavior that could be implemented. It just implements a shortcut of not invoking the Comparator’s method when both objects are identical. In other words, it does a==b? 0: c.compare(a, b), nothing more. So not breaking when both objects are null is just a side-effect. The encapsulated code might look trivial but the other methods in this class are of a similar category. Using small utility methods a lot might still result in a notable win.
By the way, it’s not a Java 8 method at all. It exists since Java 7.
Regarding your second question, Comparator.nullsFirst(…) decorates an existing Comparator and will enforce the rule for null values before delegating to the provided comparator as it is the purpose of this comparator to shield the existing one from ever seeing null values. It doesn’t matter whether the decorated comparator is a chained one or not. As long as it is what you called the “inner comparator”, as
you must not invoke thenComparing on the result of nullsFirst as that would imply calling the next comparator when both values are null.
Comparator.nullsFirst(Comparator.comparing(a).thenComparing(b)) // perfect
Comparator.nullsFirst(Comparator.comparing(a)).thenComparing(b) // ouch
Now to your third question, implementing a compareTo method using a nullsFirst comparator is violating the interface specification:
The implementor must ensure sgn(x.compareTo(y)) == -sgn(y.compareTo(x)) for all x and y. (This implies that x.compareTo(y) must throw an exception iff y.compareTo(x) throws an exception.)
This implies that passing null as argument should always result in a NullPointerException as swapping argument and receiver would throw as well, unconditionally.
Orders including a null policy should always be provided as separate Comparators.
Note that it would also be quite inefficient as you would create a new Comparator (multiple Comparators, to be precise) for every compareTo call. Now image sorting a rather large list of these objects…
What I normally do for your final question is to first create a static comparator reference within the class:
public static final Comparator<Song> COMP_DEFAULT
= nullsFirst(comparing(Song::getTitle, nullsFirst(naturalOrder()))
.thenComparing(Song::getArtist, nullsFirst(naturalOrder()))
.thenComparingInt(Song::getDuration));
And then refer to this comparator in compareTo
public int compareTo(Song other) {
return COMP_DEFAULT.compare(this, other);
}
This way you're not recreating your comparator for each compareTo call, null safety of Song is guaranteed as is the result of a.comparetTo(b) == b.compareTo(a).
We also ensure null safety of each property by using nullsFirst(naturalOrder()) for the passed in key comparator (second argument).
As the Comparator returned is immutable it can be made public which can be handy for bundling some alternate Comparators with the class that consumers may use.
I have some pieces of code in a multi-threaded environment that access a shared variable. Obviously I need to lock for these accesses, but my question is whether I save or create additional overhead by locking the variable for a short amount of time to get a value, unlocking, doing some things with what I retrieved, then re-locking to modify the data structure that I just unlocked.
Obviously for very expensive operations that can be done outside of a lock, you would benefit by not locking that segment. What about, for example, the following, where the operations being done are relatively inexpensive (creating a new object and an if statement):
Less threaded:
Value v;
lock (values)
{
v = values.FirstOrDefault(a => a.Thing == someValue);
if (v == null)
{
v = new Value { Thing = someValue };
values.Add(v);
}
}
More threaded:
Value v;
lock (values)
{
v = values.FirstOrDefault(a => a.Thing == someValue);
}
if (v == null)
{
v = new Value { Thing = someValue };
lock(values)
{
values.Add(v);
}
}
Both solutions are thread safe and both are quite readable (IMHO), but it would be nice to build into my habits the more efficient of the two, if there is even a slight difference between the two.
The second will, potentially, buy you extra performance, but realistically, it will only be an issue if the Value constructor is relatively expensive.
In the second case, you're avoiding the lock over the null check (which is very fast), but also while constructing the Value instance. This could, potentially, be a significant improvement in performance.
That being said, this is not thread safe. A second thread could add the value to the code between the two lock statements. As such, I'd recommend the first approach (realizing that you'd always have to lock values for any other operation that uses that collection).
If this lookup is a common one, a better approach might be to use ConcurrentDictionary<T,U> instead, with Thing as the key. You could then use the GetOrAdd method to safely add or retrieve the value.
The second case is not thread safe because while a thread is checking if v is null, another thread could have inserted a value equal to someValue (as you name it)
My current work project allows user-provided expressions to be evaluated in specific contexts, as a way for them to extend and influence the workflow. These expressions the usual logical ones f. To make it a bit palatable for non-programmers, I'd like to give them the option of using literal operators (e.g. and, or, not instead of &, |, !).
A simple search & replace is not sufficient, as the data might contains those words within quotes and building a parser, while doable, may not be the most elegant and efficient solution.
To make the question clear: is there a way in Groovy to allow the users to write
x > 10 and y = 20 or not z
but have Groovy evaluate it as if it were:
x > 10 && y == 20 || !z
Thank you.
Recent versions of Groovy support Command chains, so it's indeed possible to write this:
compute x > 10 and y == 20 or not(z)
The word "compute" here is arbitrary, but it cannot be omitted, because it's the first "verb" in the command chain. Everything that follows alternates between verb and noun:
compute x > 10 and y == 20 or not(z)
───┬─── ──┬─── ─┬─ ───┬─── ─┬─ ──┬───
verb noun verb noun verb noun
A command chain is compiled like this:
verb(noun).verb(noun).verb(noun)...
so the example above is compiled to:
compute(x > 10).and(y == 20).or(not(z))
There are many ways to implement this. Here is just a quick & dirty proof of concept, that doesn't implement operator precedence, among other things:
class Compute {
private value
Compute(boolean v) { value = v }
def or (boolean w) { value = value || w; this }
def and(boolean w) { value = value && w; this }
String toString() { value }
}
def compute(v) { new Compute(v) }
def not(boolean v) { !v }
You can use command chains by themselves (as top-level statements) or to the right-hand side of an assignment operator (local variable or property assignment), but not inside other expressions.
If you can swap operators like > and = for the facelets-like gt and eq, respectively, i THINK your case may be doable, though it will require a lot of effort:
x gt 10 and y eq 20 or not z
resolves to:
x(gt).10(and).y(eq).20(or).not(z)
And this will be hell to parse.
The way #Brian Henry suggested is the easiest way, though not user-friendly, since it needs the parens and dots.
Well, considering we can swap the operators, you could try to intercept the Integer.call to start expressions. Having the missing properties in a script being resolved to operations can solve your new keywords problem. Then you can build expressions and save them to a list, executing them in the end of the script. It's not finished, but i came along with this:
// the operators that can be used in the script
enum Operation { eq, and, gt, not }
// every unresolved variable here will try to be resolved as an Operation
def propertyMissing(String property) { Operation.find { it.name() == property} }
// a class to contain what should be executed in the end of the script
#groovy.transform.ToString
class Instruction { def left; Operation operation; def right }
// a class to handle the next allowed tokens
class Expression {
Closure handler; Instruction instruction
def methodMissing(String method, args) {
println "method=$method, args=$args"
handler method, args
}
}
// a list to contain the instructions that will need to be parsed
def instructions = []
// the start of the whole mess: an integer will get this called
Integer.metaClass {
call = { Operation op ->
instruction = new Instruction(operation: op, left: delegate)
instructions << instruction
new Expression(
instruction: instruction,
handler:{ String method, args ->
instruction.right = method.toInteger()
println instructions
this
})
}
}
x = 12
y = 19
z = false
x gt 10 and y eq 20 or not z
Which will give an exception, due the not() part not being implemented, but it can build two Instruction objects before failing:
[Instruction(12, gt, 10), Instruction(19, eq, 20)]
Not sure if it is worth it.
The GDK tacks on and() and or() methods to Boolean. If you supplied a method like
Boolean not(Boolean b) {return !b}
you could write something like
(x > 10).and(y == 20).or(not(4 == 1))
I'm not sure that's particularly easy to write, though.
Let say we have :
Map hm = new HashMap();
How to avoid putting duplicate values(Emplyees) in this HashMap?
I assume you are coding in Java, so:
if(!myMap.containsKey(myKey)){
myMap.put(myKey, myValue);
}
The good thing with HashMap is that the containsKey method takes constant time (or constant amortized time) regardless of the number of elements in your map so you can call it without bothering of the time it may take!
If you use an other language, the logic remains the same.
I think duplicate values in Map can be removed using this generic method if your userdefined object is overridden with equals and hashcode from object class
public static <K, V > Map<K,V> genericMethodtoDeleteMapduplicate(Map<K, V> pMap) {
Map<K,V> mapWithoutDup=new HashMap<>();
Set<V> totalvaluesPresent=new HashSet<>();
for (Map.Entry<K, V> a : pMap.entrySet()) {
if(totalvaluesPresent.add(a.getValue())){
mapWithoutDup.put(a.getKey(), a.getValue());
}
}
return mapWithoutDup;
}
Not sure what language you are using but in java for Hashmap their are:
boolean containsKey(Object key)
- Returns true if this map contains a mapping for the
specified key.
and
boolean containsValue(Object value)
- Returns true if this map maps one or more keys to the
specified value.
Just call which ever one makes more sense for you to check if the entry is already in the map, if it is then you know its a duplicate, otherwise put it in. I'm certain whatever language you are using will have something similar!!