Threading lib and Map

[Doug]

Hi,

I'm working on a concurrency library that provides tools for thread-safe apps. It simulates threads using a Timer class based on "setTimeout" that works on all Haxe targets. A macro provides Java-like synchronized blocks, plsu there are Mutexes, AtomicBool, AtomicRef, etc.  It's coming along nicely and I'll share the lib when it's done in case anyone wants it.

Anyway, I wanted to create thread-safe versions of Haxe Map and List.  List is working fine, but I'm struggling with Map.

• I tried extending Map - no go since Map is an abstract type.
• I tried creating my own abstract type "SafeMap" but I need a variable or property (the mutex for locking) and the compiler doesn't allow vars in abstract classes (which I guess makes sense).
• I tried creating a SafeMap<K,V> class, which contains a Map, but the compiler says "Abstract Map has no @:to function that accepts IMap<SafeMap.K, SafeMap.V>"

I could just create my own SafeMap independent of Map, but there are a lot of libs etc where I would like to use SafeMap in place of Map. 

I'm hoping someone can steer me in the right direction.  How do I create a class/type that overrides all the Map methods and can be used anywhere a Map can be used?

Cheers.

[Doug]

Despite banging on this for a day, and searching Google for answers, the way to handle this didn't occur to me until after posting.  I'm going to create versions of SafeMap that extend the concrete types that Map supports (eg. StringSafeMap extends StringMap... same for IntMap, EnumValueMap, ObjectMap) then I will create a SafeMap abstract type that works the same way as Map for selecting best implementation based on params.   They will all implement Map.IMap so should work in the same places Map does now.

[Jason O'Neil]

Look forward to seeing the results :)

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Laurence Taylor]

Tell me if I'm wrong, but I would dispute that setTimeout works on all targets.

The only way I've seen to unify the targets in that respect is to port libevt to neko, use libevt-php (from php react) on php, maybe reuse the neko bindings with c++, and the rest of the targets have events.

maybe that's of some use.

regards,

Laurence

[Doug]

My Timer class uses native setTimeout on targets that support it (JS, Flash), and is simulated using native threads on other targets.  In JS my concurrent classes resolve to no-op, but use native locks on other platforms.  I've got unit tests for all and so far so good.

Using this lib, you need to code using an event model ala JS setTimeout, which is a lowest common denominator.  However on platforms that support native threads the callbacks are done concurrently.  Instead of a thread loop you get a method called repeatedly at a set interval, and you get multi-threaded, thread-safe apps across platforms using a common codebase.

[Laurence Taylor]

I shall look forward to that, is it gitable?

[Doug]

Yes, Github soon as I get the threadsafe Map working.  ObjectMap inlines "get" and "exists" so I can't override those methods and make thread-safe.  Argh!

[Laurence Taylor]

There's no reason why you absolutely must override the std-lib classes, just provide an implementation of the same interface that can be dropped in, no biggie

[Juraj Kirchheim]

I'm really not quite sure why new implementations of the basic
datastructures are needed to start with.

You can create the thread safe abstract over `{ data: IMap<K, V>,
mutex:Mutex }` and simply copy and paste Map's implementation as a
basis, adding locks where necessary.

That way, anybody can plug in any implementation of IMap. Your module
is responsible for synchronizing access to a map. That's it. It can be
combined with any existent implementation of a map (e.g.
https://github.com/HaxeFoundation/haxe/blob/development/std/haxe/ds/EnumValueMap.hx#L31).

I guess this is actually a really good case for composition over inheritance :D

Regards,
Juraj

[Doug]

Thanks.  I agree, and would rather just use existing Map implementations over creating new ones.  I tried creating an abstract type but couldn't figure out how to add a var (the mutex).  Sounds like you've pointed me in a different direction, which is great, but I will have to read more about abstracts to understand how to create one "over" an object like that.

[Stephane Le Dorze]

Abstracts are an abstraction derived from an existing type and will *never* allow you to add information (like a variable) to it.

[Jason O'Neil]

Unless the existing type isn't T, but { obj:T, prop:SomethingElse } which I think is what is being suggested :)

--

[Juraj Kirchheim]

Quite simply, you abstract "over" the type that you put in parentheses.

So you would just write something like this for example:
https://gist.github.com/back2dos/6199575

Bonus point for making calc and exec a macro ;)

Regards,
Juraj

[Cristian Baluta]

Isn't the whole purpose of concurrency to not block the UI? How are you gonna do this in flash, js and maybe others?

Regards,
Juraj

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/groups/opt_out.

--
Băluță Cristian
http://ralcr.com
http://imagin.ro

[Stephane Le Dorze]

This is not in contradiction with what I've said; :)

As we're creating the abstracts over this new value { obj:T, prop:SomethingElse }, and not T.

[Stephane Le Dorze]

If you don't want to use locks, you then better use persistent (immutables) data structures or lock free ones (based on atomic operations).