While using theinversifyJS library, I saw a statement that the singleton pattern is safe because node.js is single-threaded.
How does single-threading benefit from singletons over multithreading?
It's hard to know what the author meant. One likely explanation is that a single thread can't race with itself when lazily initializing a singleton. In a multi-threaded environment, two threads could naively test whether the singleton has been initialized, then both could initialize it, meaning it's no longer truly a singleton. This could cause problems if initializing it has side effects.
Related
Currently, I am using get_it package for dependency injection. However, I have confused about singleton and lazySingleton.
I know its difference is lazySingleton will not init until it's used and reduce init time as well as saving resource. However, I don't know what is drawbacks of lazySinglton with singleton are. Why not replace all singleton with lazySingleton.
Both are Singletons. But LazySingleton refers to a class whose resource will not be initialised until it's used for the 1st time. It's generally used to save resources and memory.
Now the drawback, LazySingleton will take time when it is used for the first time. the other singleton may have been initialized in advance and the time taken to initialize might have been used to make the process faster.
I have been refactoring my Play app from using Guice to using Compile-time DI.
In Guice, when we don't decorate a class with #Singleton, many instances can be created as needed.
In compile-time DI, we create an instance to be injected once, thus I think it is equivalent to a singleton.
My question is if I would lose any performance by restricting everything to be only one instance. For example, if I have an instance serviceA, with method doSomething, and considering that everything is stateless. If I have a 32-core CPU, and lots of requests come in. Would Play, in the context of compile-time DI, be able to utilize the full capacity of the CPU?
AFAiK Guice (and other runtime DI frameworks) doesn't by default produce singletons for the sole reason to be faster when creating the instances and simplify complex (potentially cyclic) dependency graph. Their goal is to start faster.
Whether you have 1 or 2 instances of ServiceA will not affect the performance of using these instances once they are created.
It's theorically even better to have singletons.
So I just delved into the Singleton classes and yes, I find them quite helpful. I use my singletons mostly for data storage for multiple targets (views, tables etc.). That being said, I can already see myself going to implement a lot of singletons in my project.
But can a lot of singletons have a negative impact? From what I've read about singletons is that you create one instance for each of them in a proces. Other class instances get released (assuming they get released properly) from memory, then should singletons be released too?
So to narrow it down to one question: Is it harmful to have a lot of singletons?
Singletons don't scale. No matter what you think should be a singleton, when your system gets bigger, it turns out you needed more than one.
If you NEVER need more than one, a singleton is fine. However, as systems scale, you typically need more than one of anything within its own context.
Singletons are merely another way to say "global". It's not bad, but generally, it's not a good idea for systems that evolve and grow in complexity.
From GOF Book:
The Singleton pattern has several benefits:
Controlled access to sole instance. Because the Singleton class encapsulates its sole instance, it can have strict control over how
and when clients access it.
Reduced name space. The Singleton pattern is an improvement over global variables. It avoids polluting the name space with global
variables that store sole instances.
Permits refinement of operations and representation. The Singleton class may be subclassed, and it's easy to configure an application
with an instance of this extended class. You can configure the
application with an instance of the class you need at run-time.
Permits a variable number of instances. The pattern makes it easy to change your mind and allow more than one instance of the Singleton
class. Moreover, you can use the same approach to control the number
of instances that the application uses. Only the operation that grants
access to the Singleton instance needs to change.
More flexible than class operations. Another way to package a singleton's functionality is to useThe Singleton class can be
subclassed. class operations (that is, static member functions in C++
or class methods in Smalltalk). But both of these language techniques
make it hard to change a design to allow more than one instance
ofclass. Moreover, static member functions in C++ are never virtual,
so subclasses can't override them polymorphically.
Can anybody give me example that NSMutableArray is thread safe or not?
It is not thread safe. See the list of thread safe/unsafe classes here
According to the Apple docs NSMutableArray is not thread safe.
Mutable objects are generally not
thread-safe. To use mutable objects in
a threaded application, the
application must synchronize access to
them using locks. (For more
information, see “Atomic Operations”).
In general, the collection classes
(for example, NSMutableArray,
NSMutableDictionary) are not
thread-safe when mutations are
concerned. That is, if one or more
threads are changing the same array,
problems can occur. You must lock
around spots where reads and writes
occur to assure thread safety.
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html
I have a custom model class with an NSMutableData ivar that will be accessed by custom NSOperation subclasses (using an NSOperationQueue). I think I can guarantee thread-safe access to the ivar from multiple NSOperations by using dependencies, and I can guarantee that I don't access the ivar from other code (say my main app thread) by waiting until the Q has finished all operations.
Should I use a nonatomic property specification, or leave it atomic? Is there a significant impact on performance?
Andrew, whether it's significant depends on what you are doing. If your Operations are uploading movies to youtube and each operation needs to read the data once then it doesn't make the slightest bit of difference - just leave it as atomic.
Otherwise you need to profile to see if it is significant. If you are sure (you don't sound that sure) that the NSMutableData will never be accessed from two or more threads simultaneously (however you do it, lock, barriers, or just waiting) then you don't have a need for it to be atomic.
Premature optimisation is the root of all evil.
Leave it atomic until you find out for sure that there is a performance issue.
If it's a mutable object then your biggest enemy is concurrent mutation, not inconsistent property access.