genmap: Generate thread-safe, type-safe maps easily

[am...@ammar.io]

https://github.com/ammario/mapgen

Features:

• Supports any key/value pair supported by Go's native maps
• Allows complex operations via Lock() and Unlock()
• Generated code conforms to golint and gofmt
• Allows custom types
• Sensible default file name and map name
  

[Shawn Milochik]

Thanks for putting the work into this. The timing seems unfortunate, though. How does it compare to sync.Map just announced?

https://tip.golang.org/pkg/sync/#Map

[am...@ammar.io]

sync.Map isn't type safe

[alex....@gmail.com]

I do not understand what prevents the authors of the language from determining the thread-safe type cmap(name is taken for example) with builtin mutex:

X: = cmap[int]string{}

Y: = make(cmap[string]interface{})

x, exists := X[10]
y, ok := Y["some"]

In this case, the programmer might get a choice, use a fast but unsafe map or slower (but with internal mutex) cmap. It would be with a standard API, instead of stupid sync/#Map

They wrote: "grab a mutex would slow down most programs and add safety to few". Ok, give me choise to use map or cmap with similar API.

пʼятниця, 16 червня 2017 р. 12:26:04 UTC+7 користувач am...@ammar.io написав:

[Henrik Johansson]

I agree a typed concurrent map would be very neat but each type that make has to support requires AFAIK specialisation in the compiler(?) which seems to be burdensome. Perhaps backwards compatibility prohibits the use of the name 'cmap', not sure.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[am...@ammar.io]

I'm not sure it sets a good precedent adding more data structures to the language. we need generics 

[Олексій Чечель]

But it would be the most bloodless way. Go is positioned to develop various APIs and microservices. This is often associated with high loads (in my practice - always). I tired of wrapping the map into structures.
Nevertheless, I would like to hear, in occasion of generics, how this would simplify the work with the map.

вт, 11 лип. 2017 о 00:27 <am...@ammar.io> пише:

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/_7XcsQxGPi0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Rader]

I would prefer `sync.RWMutex` which allows multiple `Get` to the map.

[am...@ammar.io]

It is supported via the `--rwmu` flag.

[Haddock]

I once played a bit with thread-safe collections I wrote using Java. With the number of threads increasing throughput did not just decline a bit, it completely plummeted that I was baffled.

Class ConcurrentHashMap, which is part of Java since JDK 1.5 is divided in segments. Segments help greatly in improving throughput. Have a look at https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/util/concurrent/ConcurrentHashMap.java. If you follow the places in the code where the inner class Segment is used, you will see how it works.

Locking the entire map should only done if there is absolutely no way to avoid it like in something like this:

myThreadSafeMap.lock();
Key key = myThreadSafeMap.get("foo");
if(key != null) {
    myThreadSafeMap.put("bar", "tomato");
}
myThreadSafeMap.unlock();

If possible change to a design that avoids code like in the snippet above.