From 3787503887946998417 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,25827c9ceb81badc X-Google-Attributes: gidf78e5,public From: jcoffin@taeus.com (Jerry Coffin) Subject: Re: string/cow/algorithm Date: 1998/09/03 Message-ID: #1/1 X-Deja-AN: 387408204 Approved: Fergus Henderson References: <35D9AE1C.7553@pratique.fr> <35e47ac7.633205050@nr1.toronto.istar.net> <6s7ejv$q3h$1@shell7.ba.best.com> <35e84662.881936868@nr1.toronto.istar.net> <6selg2$64j$1@shell7.ba.best.com> <35ee5ff3.1150564574@nr1.toronto.istar.net> X-Original-Date: Wed, 2 Sep 1998 23:33:36 -0600 X-Complaints-To: abuse@rmi.net X-Trace: news1.rmi.net 904800821 3407 166.93.76.200 (3 Sep 1998 05:33:41 GMT) Organization: TAEUS X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUANe5DZuEDnX0m9pzZAQGWCAF/fCAllCBcBI5SrwGMVErKaaDUyfqD3s1z 8gah71JZgbgcqbBqjodGq9r7ZSaOziyb =XJJR NNTP-Posting-Date: 3 Sep 1998 05:33:41 GMT Newsgroups: comp.std.c++ In article <35ee5ff3.1150564574@nr1.toronto.istar.net>, herbs@cntc.com says... [ ... ] > Followup question (I will do my own research, but comments are welcome): > How efficient is a built-in "integer atomic get/set" operation compared > to a Win32 critical section (NOT a mutex, those are more expensive)? This is getting marginal for topicality, but to some extent it's probably more or less universal: critical sections in Win32 are considerably cheaper to enter IF you're the only one entering them. However, if the critical section has already been entered, they're actually somewhat more expensive than a mutex. Worse, tests have shown that critical sections have a significant problem when a large number of threads are present, even when they're not constantly contending over the critical section. Finally, the relative speed can get quite a bit worse on a multiprocessor machine. Therefore, the relative speed is hard to quantify. However, at least in my experience, the integer atomic get/set (InterlockedIncrement and InterlockedDecrement under Win32) are considerably more _dependably_ fast, even if they're not always significantly faster. I'd expect that at least part of the situation with a critical section applies to almost any environment using kernel threads: the problem is that when a thread tries to enter a critical section that's already in use, it normally wants to got to sleep and allow other threads to run. The majority of the speed gain for using a critical section in the first place (compared to using a mutex) is simply because it doesn't involve a change to kernel mode. When the thread sleeps, that causes a change to kernel mode anyway. If you're using some manner of non- kernel threads, the thread can sleep and allow other threads in the same process to run without switching to kernel mode. -- Later, Jerry. The Universe is a figment of its own imagination. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]