June 22, 2012
Hey,

In core.thread:suspend(), there is this comment:

                // NOTE: It's really not ideal to wait for each thread to
                //       signal individually -- rather, it would be better to
                //       suspend them all and wait once at the end.  However,
                //       semaphores don't really work this way, and the obvious
                //       alternative (looping on an atomic suspend count)
                //       requires either the atomic module (which only works on
                //       x86) or other specialized functionality.  It would
                //       also be possible to simply loop on sem_wait at the
                //       end, but I'm not convinced that this would be much
                //       faster than the current approach.
                sem_wait( &suspendCount );

Has this turned out to be a performance problem in practice? These days, core.atomic works everywhere (LDC and GDC use intrinsics), so using that should be trivial. But I don't want to bother with this if no one has had performance problems with this suspension strategy anyway.

Regards,
Alex
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

June 22, 2012
On Jun 22, 2012, at 1:19 PM, Alex Rønne Petersen wrote:

> Hey,
> 
> In core.thread:suspend(), there is this comment:
> 
>                // NOTE: It's really not ideal to wait for each thread to
>                //       signal individually -- rather, it would be better to
>                //       suspend them all and wait once at the end.  However,
>                //       semaphores don't really work this way, and the obvious
>                //       alternative (looping on an atomic suspend count)
>                //       requires either the atomic module (which only works on
>                //       x86) or other specialized functionality.  It would
>                //       also be possible to simply loop on sem_wait at the
>                //       end, but I'm not convinced that this would be much
>                //       faster than the current approach.
>                sem_wait( &suspendCount );
> 
> Has this turned out to be a performance problem in practice? These days, core.atomic works everywhere (LDC and GDC use intrinsics), so using that should be trivial. But I don't want to bother with this if no one has had performance problems with this suspension strategy anyway.

No one has complained, but this isn't a performance issue that could really be seen from the user side.  It would definitely speed up the suspend process, but this is such a small part of the collection process that the actual difference may be negligible.  It would be easy enough to change to looping on sam_wait at the end though, and see if there's any difference.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime