Hi David,

Le 20 sept. 07 à 22:02, David Chisnall a écrit :

> Hi everyone,
>
> I've finally got around to doing the optimisation on EtoileThread
> that I've been planning for a while.  ETThreadedObject now uses a
> lockless ring buffer when there are invocations in the queue (which
> is more efficient than the NSMutableArray previously used), and
> doesn't use any of the (expensive) POSIX threading locking operations
> when there are objects in the queue (until the buffer is full, and
> then it uses a spinlock in the calling thread to wait for the buffer
> to empty).  When the buffer is empty, it switches back to using
> locking and waits on a condition variable, reducing polling overhead.
>
> When there are not many messages being sent from one thread to
> another, the overhead is the same as it was (actually, slightly
> lower, since a static array is being used, rather than an
> NSMutableArray).

I have a question about the ring buffer, what is the purpose of  
consumer/producer variables which are incremented or decremented?

> When there are a lot of messages, we are now just doing a small
> amount of pointer arithmetic, rather than issuing six system calls,
> which should improve performance considerably.

Nice.

> This is new code, and hasn't been heavily tested, so I'd appreciate
> any bug reports (or fixes).

I plan to use in EtoileUI, but probably not for 0.3. I will have to  
think about the right concurrency model for the framework.
CoreObject will probably use it too…

Do you think the following proposition is possible and/or  
interesting… We very often experiment potential micro-blocking at UI  
level (of one or two seconds or even half a second) and threads  
aren't very efficient in such cases. My proposition is to have a base  
class ETActorObject, two subclasses ETCoroutinedObject and  
ETThreadedObject. Most of the time we would just instantiate an  
ETActorObject relying behind the scene (or returning) an  
ETCoroutinedObject by default. In addition to that, a rudimentary  
scheduler would monitor coroutines and turns any of them that runs  
for too long (an amount of time that can be adjusted per application)  
into an ETThreadedObject to benefits of real multiprocessing provided  
by OS and hardware.

Cheers,
Quentin.


_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev

Reply via email to