On Mon, 5 Dec 2016 11:35:34 -0200 Felipe Magno de Almeida <felipe.m.alme...@gmail.com> said:
> On Mon, Dec 5, 2016 at 12:04 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Sun, 4 Dec 2016 23:23:39 -0200 Felipe Magno de Almeida > > <felipe.m.alme...@gmail.com> said: > > > >> On Dec 4, 2016 10:55 PM, "Jean-Philippe André" <j...@videolan.org> wrote: > >> > >> Nah I totally agree with Vincent that the error message is cryptic. > >> > >> Anyway as far as I remember shared objects are not a viable solution until > >> we change the calling mechanism (function & data resolution) to be > >> thread-safe, rather than locking the entire pool of shared objects for the > >> entire duration of a call. > >> > >> > >> Indeed. just like we discussed in Korea. the recursive mutex must go. > > > > i then invite you to actually implement all the fine-grained locks for every > > class and object now and into the future and never to get it wrong. are you > > going to do that? > > Good point. I'll see what I can do. I would like to implement the multiple > loops and threading anyway, with the design we discussed. This seems > to be a part of this work. We also always have the option of sending objects from thread/loop to thread. as long as the object has no links to other objects (references or children etc.) then it's easy. this honestly would be the fast path. shared objects are a slow path. keep in mind that mutexes, spjnlocks and even atomic instructions are SLOW PATHS in a cpu. they take a LOT longer to execute than a normal "instruction" or even smallish function that they should be. They have to put in memory barriers and force cache synchronization between cores etc. so shared objects being "heavy when there is contention" is pretty normal. in fact a single lock on entry and unlock on exit is about as efficient as can be done. remember you can do_super() and access other objects, children and parents and so on so having a single recursive mutex frankly was the sanest thing i could think of that balanced simplicity, ease of maintainability into the future (having to by hand put in locks in every method call is going to be nuts and having to have shared vs non-shared versions of base class etc.). thinking about all the work needed for fine-grained locking just made me do it this way. this way at least you DON'T every have to write locking code. simply declare your object as shared on creation. of course the class has to be sharing-friendly but this is the same with or without fine grained locks. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
