Share via

GetPrivateProfileString/WritePrivateProfileString

  • Article

Learned a hard lesson. Contention between GetPrivateProfileString and WritePrivateProfileString may cause a deadlock, even for multiple processes. If you intent to Read/Write the same ini file, you have to lock the file yourself.

Yes, I know they are marked as deprecated. But they are really handy when you only have small settings. I don't want to use the registry for everything.

So wish the OS can make it thread safe.

Comments

  • Anonymous
    February 05, 2004
    The comment has been removed
  • Anonymous
    February 05, 2004
    I don't use registry. That is why I use GetPrivateProfileString. I only use C++ now so I don't have the luxury of System.Xml.dll, and I can't afford dependency on msxml.dll.

    Now talking about System.Xml.dll, have you watched Rico Mariani's performance video? http://gotdotnet.com/team/clr/about_clr_performance.aspx. Your usage of System.Xml is one of the evil thing he mentioned specifically;)
  • Anonymous
    February 05, 2004
    Now where it would hit I would imagine is when you use the XmlSerializer I guess for serialization and deserialization when sending over the wire. So what other mechanism do they propose for sending data over wires? Back to the dark ages of custom binary formats?
  • Anonymous
    February 05, 2004
    Anytime you dip into a file you will get a perf hit, thats why alot of the hidden files for windows have the information like GUIDs as part of the filename, its faster to read the name than dip into a file.

    I dont use the Xml class where its performance critical, its just configuration settings. Its not like im reading and writing encrypted Xml files during a critical operation.
  • Anonymous
    February 05, 2004
    There is a bug on the operation of those Ini file operations between 95, NT and 2000 If I remember correctly. There is a slight behaviour difference when using # comments and tabs and spaces and why I had to implement my own wrapper and parse alot in a compatible way for all systems (not much of a problem now that we moved on but it sure was then.)

  • Anonymous
    February 06, 2004
    I try to keep it simple. No comments, no tabs.
  • Anonymous
    February 06, 2004
    >So wish the OS can make it thread safe.

    How can the OS make them thread-safe, especially in a cross-process case? By locking a named mutex each time WritePrivateProfileString for a specific file is called? Then what if I don't need synchronization - why should I have to pay for it? Or what if I need to do the update as part of a larger operation that needs to be atomic as a whole? The built-in mutex would be useless for me and I would have to do my own locking anyway.

    It's a classic design problem (I think it's even mentioned in the .NET Design Guidelines). It's better to let the applications decide how to synchronize and if they need synchronization at all.
  • Anonymous
    February 06, 2004
    By saying make it thread safe, I really mean not deadlock. How will I know Read/Write contention will cause a deadlock?

    And in general I agree with you. Synchronization decision is better made in application.
  • Anonymous
    February 06, 2004
    Yes because ini files are self describing. No comments are good.

    Its still a bug :P
  • Anonymous
    June 09, 2009
    PingBack from http://cellulitecreamsite.info/story.php?id=2629