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 (10)

  1. moo says:

    You use the registry? What on earth for the registery wont version well will it.

    Its much simpler to use XML and load the Xml with XmlDocument.Load(filename) then call .SelectSingleNode(xPath) where xPath is Root/IniSection/IniKey etc You can even encrypt this and store it securely then you can decrypt and call XmlDocument.LoadXml(decryptedXml); You can nest much more to match the actual structure of the configuration than ini file ever could.

    Thats what I do anyway 😀 Works a charm for me.

    I always try to keep all applications local and relative and avoid the registry where I can, its also more secure as it wont leave application poo all over the system that may be a security risk or privacy leak.

    Registry is a no no for me.

  2. 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? Your usage of System.Xml is one of the evil thing he mentioned specifically;)

  3. moo says:

    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?

  4. moo says:

    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.

  5. moo says:

    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.)

  6. I try to keep it simple. No comments, no tabs.

  7. Pavel Lebedinsky says:

    >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.

  8. 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.

  9. moo says:

    Yes because ini files are self describing. No comments are good.

    Its still a bug 😛

Skip to main content