RE: Reference counting in UnicodeString

 

>-----Original Message-----
>From: Brown, Brooks [mailto:[email protected]] 
>Sent: Monday, December 13, 2004 1:57 PM
>To: Robert Buck; Deborah Goldsmith
>Cc: [email protected]
>Subject: RE: Reference counting in UnicodeString
>
>Thanks for the information.  What platform are the pthreads 
>statistics from?

Debian Linux.


>-----Original Message-----
>From: Robert Buck [mailto:[email protected]]
>Sent: Monday, December 13, 2004 5:33 AM
>To: Deborah Goldsmith; Brown, Brooks
>Cc: [email protected]
>Subject: RE: Reference counting in UnicodeString
>
>
>Here are some perf stats (cycle counts per operation) for 
>common synch operations. First column is pthreads, second 
>column is Windows.
>
>Windows atomic inc/dec/add/cas style APIs take on the order of 
>12-25 cycles to complete. The inc/dec/ APIs are closer to 12 
>cycles, but can spike up to 25; the cas style APIs are closer 
>to 25 cycles, may spike a little higher.
>
>acquire a lock (uncontested)
>  mutex                               84    822 
>  critical_section                    N/A    20 
>release a lock
>  mutex                               81    758 
>  critical_section                    N/A    17 
>
>acquire/decrement semaphore           143   824 
>release/increment semaphore           144   767 
>
>allocate a key for thread-local storage
>  1st key                             255   260 
>delete a key for thread-local storage
>  last key                            250   968 
>set thread-local storage              102    52 
>retrieve thread-local storage         131    51 
> 
>For many applications, in the big picture, 84 cycles is in the noise.
>
>
>>-----Original Message-----
>>From: [email protected]
>>[mailto:[email protected]] On Behalf Of Deborah 
>>Goldsmith
>>Sent: Friday, December 10, 2004 5:12 PM
>>To: Brown, Brooks
>>Cc: [email protected]
>>Subject: Re: Reference counting in UnicodeString
>>
>>pthread_mutex_lock isn't that bad. It's used quite a bit in Mac OS X. 
>>If there's no contention I think it's pretty fast.
>>
>>In addition, I'm looking into adding support for non-blocking 
>reference 
>>counting when building and running ICU on Darwin (which 
>includes Mac OS 
>>X). This would only be active on Mac OS X 10.4 or later 
>(Darwin 8.0 or 
>>later), however; on earlier releases you'd get pthread_mutex_lock.
>>
>>Deborah Goldsmith
>>Internationalization, Unicode liaison
>>Apple Computer, Inc.
>>[email protected]
>>
>>On Dec 10, 2004, at 12:35 PM, Brown, Brooks wrote:
>>
>>> We are considering using ICU's UnicodeString as a cross platform 
>>> string class.  (The platforms we need to support are MacOS
>>10.2.8 and
>>> Windows 2000 or better.)  The UnicodeString class has many
>>features we
>>> want, but I am concerned about the use of pthread_mutex_lock on 
>>> non-Windows platforms for safe reference counting.
>>>
>>> Is the optimization of sharing buffers for string data really worth 
>>> all the thread synchronization that can occur?  Normally, when you 
>>> copy a string, you modify it in the next statement, so you need to 
>>> allocate a new buffer and copy anyway.
>>>
>>> Should there be a compiler option to disable the behind-the-scenes 
>>> sharing of buffers between strings?  (Excluding read only aliases, 
>>> since those aren't reference counted.)
>>>
>>> Brooks R. Brown
>>> Software Engineer
>>> Extensis, Inc.
>>> <http://www.extensis.com/>
>>> phone: 503.274.2020 x130
>>> email: [email protected]
>>>
>>> Empowering digital assets
>>>
>>> Notice:  This communication may contain privileged or other 
>>> confidential information.  If you are not the intended 
>recipient, or 
>>> believe that you have received this communication in error,
>>please do
>>> not print, copy, retransmit, disseminate, or otherwise use the 
>>> information.  Also, please indicate to the sender that you have 
>>> received this email in error, and delete the copy you
>>received.  Thank
>>> you.
>>>
>>
>>_______________________________________________
>>icu mailing list
>>[email protected]
>>http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu
>>
>