Let's imagine I want to design a system similar to crowdfunding or to the auction. There is a fixed period of time for which such an event is running. Can I start a background thread that will periodically check whether the end time if the event has been reached and subsequently closes that event? I was looking into the futures crate (and some others) but is it usable within the Substrate? Is there any best practice on how to handle such scenarios?
I believe the answer to futures is no. Here's more explanation:
I think it is better to think about what programming primitives are available inside a Substrate runtime, instead of trying to use a concept from general purpose programming (future) and try and re-purpose it for the Substrate runtime (top-down vs. bottom-up viewpoint).
So, let's think about the lifecycle of a runtime and see what makes sense there:
Inside a runtime, you are kinda stuck in a box. A (wasm) runtime code is spawned and executed by the (always native) client whenever a new block is there to be imported (or authored, but let's assume just importing for now), and killed and set aside afterwards (at least from the perspective of the runtime -- the client has runtime caching). My point being, anything that you don't commit to state (i.e. write in storage) at the end of the execution of each block is lost. This includes all the local variables, stack, heap, and anything else. So even if you were to use a future to spawn a task, that doesn't really fit into the programming model of Substrate runtimes, because even if that future lived in the runtime, as soon as the block is done, the wasm instance is dead and so is the future.
That is all ignoring the fact that you can only use crates that support no_std in the runtime, so not every async library will be available anyhow.
The main solution, as I hinted, is probably something that uses state storage to record the starting point of the auction, so that x blocks later you can still know when you started it, and if some threshold is passed, then you can finish your auction. You could use either a timestamp or a number of blocks for your duration of auction. Something along the lines of:
trait Config: frame_system::Config {
// duration in time or block number
type AuctionDuration<T::BlockNumber>;
}
// inside your on_initialize
fn on_initialize(n: T::BlockNumber) {
if n % T::AuctionDuration::get() == 0 {
// ^^^^^ note: ensure this is non-zero, else panic in runtime might happen.
// time to close the auction.
}
}
Related
I'm successfully using a mpsc::channel() to send messages from a producer thread to a consumer.
The consumer is only ever interested in the latest message. (It uses the message from the previous check if there is no new message.)
In consequence, I'm running the consumer's try_recv() in a loop until it fails to get a new message, and then using the last received message, or the old one if no new messages were found.
Memory is being wasted storing old messages which the consumer will throw away.
How would I build a one-element variant of mpsc::channel()?
(I've considered using sync::Mutex<Option<MyMessage>> but it is critical that the consuming thread blocks for as little time as possible. Also, I want ownership to pass from the producer to the consumer.)
You can do it with an AtomicPtr, whose compare_exchange method should compile to a simple cmpxchg instruction, allowing you to store either std::ptr::null or an actual message.
There's quite a few possibilities, with various trade-offs.
I'd recommend the arc-swap crate (see below) for a safe and fast interface, and the DIY Double Buffering approach if performance is that critical.
std::mpsc
There's a second option for std::mpsc: the sync_channel function creates a bounded channel, where the sender blocks when the channel is full, until the receiver picks off a message.
I do not think that it is ideal for your usecase.
Tokio Watch channel
The Tokio ecosystem has the watch channel designed for the purpose of propagating configuration changes.
Unfortunately it is designed for multiple consumers, so the consumers borrow the messages: there is no transfer of ownership.
Arc Swap
I believe the arc-swap crate may be closer to what you need. As the name implies, it provides the moral equivalent of an Atomic<Arc<T>>.
You can use the ArcSwapOption<T> to have the equivalent of an Atomic<Option<Arc<T>>>, and the consumer can simply perform a let new = atomic.swap(None); then check if new is None (nothing new) or Some(Arc<T>) in which case it received an updated configuration.
Do be mindful of the cost of the dropping the previous Arc<T> when swapping a new one in: free is typically more expensive than malloc.
Back to std
You could use an AtomicPtr<T>. It'll require you to use unsafe, and would be a smidgen faster than ArcSwap by virtue of avoiding the reference counting.
It would suffer from the same drop issue, though.
DIY Double Buffering
You could also simply Do It Yourself. A simple double-buffering storage would work.
By storing a plain Option<T>, you avoid the additional extra allocation (and thus extra de-allocation), at the cost of making the check itself slower -- as you may now need to check both buffers. It may be possible to check a single buffer, not clear.
I'm curious about TCP/IP(multi threads), one program did change the var and can another program cognize the change of var while in loop?
The reason why I'm curious is I am making a simple game and it has a lobby to wait for another player to come in, but in the same client. I think there is no way of waiting for another player.
I made while(ready = 0) loop and when one client enters the room changing the var(ready) = 1 so I send it to the server, but roommaker client couldn't break the loop....
Here is my code:
while(1){
recv(socket,a,sizeof(a),0);
ready = atoi(ready);
if(ready = 1){
break;
}
}
Why does it happen?
The question (if I understand it correctly) is asking if, when thread A sets a variable to a new value, if thread B will "see" the variable's value change.
The short answer is "possibly, but you shouldn't depend on it, because having threads share read/write access to a value like that is undefined behavior and it often won't behave the way you want it to". If you are going to share a variable between threads, you need to either guard access (both read and write) to that value with a mutex, or (in C++) use a std::atomic variable instead of a regular int/bool/etc datatype.
The reason why sharing a plain old variable doesn't work reliably is because computers are very sophisticated now -- the compiler will play a lot of clever tricks to make your program's executable code more efficient, and also modern CPUs will play even more clever tricks at run time to make things faster still. However, neither the compiler nor the CPU "knows" that your ready variable is intended to be shared across threads; in fact they will both assume that it won't be, in order to perform optimizations -- such as caching the value of the variable in a CPU register so that the thread doesn't have to re-read it from RAM every time through the loop. When that optimization occurs, thread A can change the value of ready, but that change may or may not make it out to RAM in a timely manner, and even if it does, thread B may or may not notice the change in RAM (i.e. if it has already cached that value in a register, it won't).
So, the advice is: don't share a plain variable like that -- it's a race condition and your program likely won't work the way you intended. For multithreaded programs you have to be very careful to synchronize shared variables, either with mutexes or (in C++) by using std::atomic types (which tell the compiler that the variables are intended to be shared across threads, so that it can take additional steps to make sure the correct things happen when they are read or written).
Wanting to be sure we're using the correct synchronization (and no more than necessary) when writing threadsafe code in JRuby; specifically, in a Puma instantiated Rails app.
UPDATE: Extensively re-edited this question, to be very clear and use latest code we are implementing. This code uses the atomic gem written by #headius (Charles Nutter) for JRuby, but not sure it is totally necessary, or in which ways it's necessary, for what we're trying to do here.
Here's what we've got, is this overkill (meaning, are we over/uber-engineering this), or perhaps incorrect?
ourgem.rb:
require 'atomic' # gem from #headius
SUPPORTED_SERVICES = %w(serviceABC anotherSvc andSoOnSvc).freeze
module Foo
def self.included(cls)
cls.extend(ClassMethods)
cls.send :__setup
end
module ClassMethods
def get(service_name, method_name, *args)
__cached_client(service_name).send(method_name.to_sym, *args)
# we also capture exceptions here, but leaving those out for brevity
end
private
def __client(service_name)
# obtain and return a client handle for the given service_name
# we definitely want to cache the value returned from this method
# **AND**
# it is a requirement that this method ONLY be called *once PER service_name*.
end
def __cached_client(service_name)
##_clients.value[service_name]
end
def __setup
##_clients = Atomic.new({})
##_clients.update do |current_service|
SUPPORTED_SERVICES.inject(Atomic.new({}).value) do |memo, service_name|
if current_services[service_name]
current_services[service_name]
else
memo.merge({service_name => __client(service_name)})
end
end
end
end
end
end
client.rb:
require 'ourgem'
class GetStuffFromServiceABC
include Foo
def self.get_some_stuff
result = get('serviceABC', 'method_bar', 'arg1', 'arg2', 'arg3')
puts result
end
end
Summary of the above: we have ##_clients (a mutable class variable holding a Hash of clients) which we only want to populate ONCE for all available services, which are keyed on service_name.
Since the hash is in a class variable (and hence threadsafe?), are we guaranteed that the call to __client will not get run more than once per service name (even if Puma is instantiating multiple threads with this class to service all the requests from different users)? If the class variable is threadsafe (in that way), then perhaps the Atomic.new({}) is unnecessary?
Also, should we be using an Atomic.new(ThreadSafe::Hash) instead? Or again, is that not necessary?
If not (meaning: you think we do need the Atomic.news at least, and perhaps also the ThreadSafe::Hash), then why couldn't a second (or third, etc.) thread interrupt between the Atomic.new(nil) and the ##_clients.update do ... meaning the Atomic.news from EACH thread will EACH create two (separate) objects?
Thanks for any thread-safety advice, we don't see any questions on SO that directly address this issue.
Just a friendly piece of advice, before I attempt to tackle the issues you raise here:
This question, and the accompanying code, strongly suggests that you don't (yet) have a solid grasp of the issues involved in writing multi-threaded code. I encourage you to think twice before deciding to write a multi-threaded app for production use. Why do you actually want to use Puma? Is it for performance? Will your app handle many long-running, I/O-bound requests (like uploading/downloading large files) at the same time? Or (like many apps) will it primarily handle short, CPU-bound requests?
If the answer is "short/CPU-bound", then you have little to gain from using Puma. Multiple single-threaded server processes would be better. Memory consumption will be higher, but you will keep your sanity. Writing correct multi-threaded code is devilishly hard, and even experts make mistakes. If your business success, job security, etc. depends on that multi-threaded code working and working right, you are going to cause yourself a lot of unnecessary pain and mental anguish.
That aside, let me try to unravel some of the issues raised in your question. There is so much to say that it's hard to know where to start. You may want to pour yourself a cold or hot beverage of your choice before sitting down to read this treatise:
When you talk about writing "thread-safe" code, you need to be clear about what you mean. In most cases, "thread-safe" code means code which doesn't concurrently modify mutable data in a way which could cause data corruption. (What a mouthful!) That could mean that the code doesn't allow concurrent modification of mutable data at all (using locks), or that it does allow concurrent modification, but makes sure that it doesn't corrupt data (probably using atomic operations and a touch of black magic).
Note that when your threads are only reading data, not modifying it, or when working with shared stateless objects, there is no question of "thread safety".
Another definition of "thread-safe", which probably applies better to your situation, has to do with operations which affect the outside world (basically I/O). You may want some operations to only happen once, or to happen in a specific order. If the code which performs those operations runs on multiple threads, they could happen more times than desired, or in a different order than desired, unless you do something to prevent that.
It appears that your __setup method is only called when ourgem.rb is first loaded. As far as I know, even if multiple threads require the same file at the same time, MRI will only ever let a single thread load the file. I don't know whether JRuby is the same. But in any case, if your source files are being loaded more than once, that is symptomatic of a deeper problem. They should only be loaded once, on a single thread. If your app handles requests on multiple threads, those threads should be started up after the application has loaded, not before. This is the only sane way to do things.
Assuming that everything is sane, ourgem.rb will be loaded using a single thread. That means __setup will only ever be called by a single thread. In that case, there is no question of thread safety at all to worry about (as far as initialization of your "client cache" goes).
Even if __setup was to be called concurrently by multiple threads, your atomic code won't do what you think it does. First of all, you use Atomic.new({}).value. This wraps a Hash in an atomic reference, then unwraps it so you just get back the Hash. It's a no-op. You could just write {} instead.
Second, your Atomic#update call will not prevent the initialization code from running more than once. To understand this, you need to know what Atomic actually does.
Let me pull out the old, tired "increment a shared counter" example. Imagine the following code is running on 2 threads:
i += 1
We all know what can go wrong here. You may end up with the following sequence of events:
Thread A reads i and increments it.
Thread B reads i and increments it.
Thread A writes its incremented value back to i.
Thread B writes its incremented value back to i.
So we lose an update, right? But what if we store the counter value in an atomic reference, and use Atomic#update? Then it would be like this:
Thread A reads i and increments it.
Thread B reads i and increments it.
Thread A tries to write its incremented value back to i, and succeeds.
Thread B tries to write its incremented value back to i, and fails, because the value has already changed.
Thread B reads i again and increments it.
Thread B tries to write its incremented value back to i again, and succeeds this time.
Do you get the idea? Atomic never stops 2 threads from running the same code at the same time. What it does do, is force some threads to retry the #update block when necessary, to avoid lost updates.
If your goal is to ensure that your initialization code will only ever run once, using Atomic is a very inappropriate choice. If anything, it could make it run more times, rather than less (due to retries).
So, that is that. But if you're still with me here, I am actually more concerned about whether your "client" objects are themselves thread-safe. Do they have any mutable state? Since you are caching them, it seems that initializing them must be slow. Be that as it may, if you use locks to make them thread-safe, you may not be gaining anything from caching and sharing them between threads. Your "multi-threaded" server may be reduced to what is effectively an unnecessarily complicated, single-threaded server.
If the client objects have no mutable state, good for you. You can be "free and easy" and share them between threads with no problems. If they do have mutable state, but initializing them is slow, then I would recommend caching one object per thread, so they are never shared. Thread[] is your friend there.
Actually I am using visual C++ to try to bind lua functions as callbacks for socket events(in another thread). I initialize the lua stuff in one thread and the socket is in another thread, so every time the socket sends/receives a message, it will call the lua function and the lua function determines what it should do according to the 'tag' within the message.
So my questions are:
Since I pass the same Lua state to lua functions, is that safe? Doesn't it need some kinda protection? The lua functions are called from another thead so I guess they might be called simultaneously.
If it is not safe, what's the solution for this case?
It is not safe to call back asynchronously into a Lua state.
There are many approaches to dealing with this. The most popular involve some kind of polling.
A recent generic synchronization library is DarkSideSync
A popular Lua binding to libev is lua-ev
This SO answer recommends Lua Lanes with LuaSocket.
It is not safe to call function within one Lua state simultaneously in multiple threads.
I was dealing with the same problem, since in my application all basics such as communication are handled by C++ and all the business logic is implemented in Lua. What I do is create a pool of Lua states that are all created and initialised on an incremental basis (once there's not enough states, create one and initialise with common functions / objects). It works like this:
Once a connection thread needs to call a Lua function, it checks out an instance of Lua state, initialises specific globals (I call it a thread / connection context) in a separate (proxy) global table that prevents polluting the original global, but is indexed by the original global
Call a Lua function
Check the Lua state back in to the pool, where it is restored to the "ready" state (dispose of the proxy global table)
I think this approach would be well suited for your case as well. The pool checks each state (on an interval basis) when it was last checked out. When the time difference is big enough, it destroys the state to preserve resources and adjust the number of active states to current server load. The state that is checked out is the most recently used among the available states.
There are some things you need to consider when implementing such a pool:
Each state needs to be populated with the same variables and global functions, which increases memory consumption.
Implementing an upper limit for state count in the pool
Ensuring all the globals in each state are in a consistent state, if they happen to change (here I would recommend prepopulating only static globals, while populating dynamic ones when checking out a state)
Dynamic loading of functions. In my case there are many thousands of functions / procedures that can be called in Lua. Having them constantly loaded in all states would be a huge waste. So instead I keep them byte code compiled on the C++ side and have them loaded when needed. It turns out not to impact performance that much in my case, but your mileage may vary. One thing to keep in mind is to load them only once. Say you invoke a script that needs to call another dynamically loaded function in a loop. Then you should load the function as a local once before the loop. Doing it otherwise would be a huge performance hit.
Of course this is just one idea, but one that turned out to be best suited for me.
It's not safe, as the others mentioned
Depends on your usecase
Simplest solution is using a global lock using the lua_lock and lua_unlock macros. That would use a single Lua state, locked by a single mutex. For a low number of callbacks it might suffice, but for higher traffic it probably won't due to the overhead incurred.
Once you need better performance, the Lua state pool as mentioned by W.B. is a nice way to handle this. Trickiest part here I find synchronizing the global data across the multiple states.
DarkSideSync, mentioned by Doug, is useful in cases where the main application loop resides on the Lua side. I specifically wrote it for that purpose. In your case this doesn't seem a fit. Having said that; depending on your needs, you might consider changing your application so the main loop does reside on the Lua side. If you only handle sockets, then you can use LuaSocket and no synchronization is required at all. But obviously that depends on what else the application does.
I am using shared variables on perl with use threads::shared.
That variables can we modified only from single thread, all other threads are only 'reading' that variables.
Is it required in the 'reading' threads to lock
{
lock $shared_var;
if ($shared_var > 0) .... ;
}
?
isn't it safe to simple verification without locking (in the 'reading' thread!), like
if ($shared_var > 0) ....
?
Locking is not required to maintain internal integrity when setting or fetching a scalar.
Whether it's needed or not in your particular case depends on the needs of the reader, the other readers and the writers. It rarely makes sense not to lock, but you haven't provided enough details for us to determine what your needs are.
For example, it might not be acceptable to use an old value after the writer has updated the shared variable. For starters, this can lead to a situation where one thread is still using the old value while the another thread is using the new value, a situation that can be undesirable if those two threads interact.
It depends on whether it's meaningful to test the condition just at some point in time or other. The problem however is that in a vast majority of cases, that Boolean test means other things, which might have already changed by the time you're done reading the condition that says it represents a previous state.
Think about it. If it's an insignificant test, then it means little--and you have to question why you are making it. If it's a significant test, then it is telltale of a coherent state that may or may not exist anymore--you won't know for sure, unless you lock it.
A lot of times, say in real-time reporting, you don't really care which snapshot the database hands you, you just want a relatively current one. But, as part of its transaction logic, it keeps a complete picture of how things are prior to a commit. I don't think you're likely to find this in code, where the current state is the current state--and even a state of being in a provisional state is a definite state.
I guess one of the times this can be different is a cyclical access of a queue. If one consumer doesn't get the head record this time around, then one of them will the next time around. You can probably save some processing time, asynchronously accessing the queue counter. But here's a case where it means little in context of just one iteration.
In the case above, you would just want to put some locked-level instructions afterward that expected that the queue might actually be empty even if your test suggested it had data. So, if it is just a preliminary test, you would have to have logic that treated the test as unreliable as it actually is.