June 22, 2012 [D-runtime] About a suspension comment in core.thread | ||||
---|---|---|---|---|
| ||||
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 Re: [D-runtime] About a suspension comment in core.thread | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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 |
Copyright © 1999-2021 by the D Language Foundation