I change task priorities based my algorithm now I want gives this tasks to vms , How I can do it in cloudsim?
you can set the 'classType' parameter of cloudLet object from your algorithm to priorotize them.
There's a method bindCloudletToVm of the class DatacenterBroker. You can refer this
Related
Is there a way to set variables in Task 1 and pass them to the child task? It looks like every task has a different session so value of variable doesn't transfer in a task tree.
Check out SYSTEM$SET_RETURN_VALUE:
Explicitly sets the return value for a task.
In a tree of tasks, a task can call this function to set a return
value. Another task that identifies this task as the predecessor task
(using the AFTER keyword in the task definition) can retrieve the
return value set by the predecessor task.
There is an example in the link.
For some reason my object at the creation time does not pick configuration passed by test. I don't see GET when I enable tracing, only SET.
I have object as following:
class top_env_cfg extends uvm_object;
int set_default_env = 1;
`uvm_object_utils_begin(top_env_cfg)
`uvm_field_int(set_default_env,UVM_DEFAULT);
`uvm_object_utils_end
function new(string name = "top_env_cfg");
super.new(name);
endfunction
endclass
In my test, inside the build_phase I am doing the following:
uvm_config_db#(int)::set(this, "*", "set_default_env" ,0);
In my environment in build_phase I am creating this object as:
env_cfg = top_env_cfg::type_id::create("env_cfg", this);
After creating this object the set_default_env still 1.
What may be wrong, and how I can debug this.
Thanks in advance.
The important thing to understand about the "automated retrieval of config_db resources" is that it does not actually happen automatically. This Verilab paper explains what happens under the hood, and I am quoting the relevant section here:
[...] one question that is often asked with respect to retrieving data is:
do you always have to explicitly call the get() function? The short
answer is that it depends. In the UVM, there are mechanisms to
automate the retrieval of data from the configuration database. In
order to have the resource automatically retrieved two things must
happen:
First, that resource has to be registered with the factory using the field automation macros.
Second, super.build_phase(phase) must be called in the build_phase() function.
The "automated" retrieval will happen when you call super.build_phase() from a uvm_component. In the case that you are referring to in your question, you have a uvm_object (you don't have a UVM build_phase), so you would need to explicitly perform a uvm_config get() call in order to retrieve the resource from the database.
I'd like to be able to run Gatling via SBT and parameterize the number of constant users per second and the total duration of the simulation.
Something like:
setUp(testScenario.inject(constantUsersPerSec(<parameter>) during(<number> <seconds|minutes|hours>))
What would be the best way to pass arguments to SBT and read them in the Simulation class?
You can try pass them as environment parameters
val variable = Option(System.getProperty("variable")) getOrElse """default_value"""
and set them in the command : -Dvariable=yourValue
I'm trying to evaluate Apache Flink for the use case we're currently running in production using custom code.
So let's say there's a stream of events each containing a specific attribute X which is a continuously increasing integer. That is a bunch of contiguous events have this attributes set to N, then the next batch has it set to N+1 etc.
I want to break the stream into windows of events with the same value of X and then do some computations on each separately.
So I define a GlobalWindow and a custom Trigger where in onElement method I check the attribute of any given element against the saved value of the current X (from state variable) and if they differ I conclude that we've accumulated all the events with X=CURRENT and it's time to do computation and increase the X value in the state.
The problem with this approach is that the element from the next logical batch (with X=CURRENT+1) has been already consumed but it's not a part of the previous batch.
Is there a way to put it back somehow into the stream so that it is properly accounted for the next batch?
Or maybe my approach is entirely wrong and there's an easier way to achieve what I need?
Thank you.
I think you are on a right track.
Trigger specifies when a window can be processed and results for a window can be emitted.
The WindowAssigner is the part which says to which window element will be assigned. So I would say you also need to provide a custom implementation of WindowAssigner that will assign same window to all elements with equal value of X.
A more idiomatic way to do this with Flink would be to use stream.keyBy(X).window(...). The keyBy(X) takes care of grouping elements by their particular value for X. You then apply any sort of window you like. In your case a SessionWindow may be a good choice. It will fire for each key after that key hasn't been seen for some configurable period of time.
This approach will be much more robust with regard to unordered data which you must always assume in a stream processing system.
I've got a question about "rwlocks", especial about "rwlockattr".
I've got a linked list with several threads working with. Every Member on this list has got a "rwlock". So now I want to set up a rule to secure that threads who want access a write-lock have a higher priority. My intention is to use
int pthread_rwlockattr_setkind_np(pthread_rwlockattr_t *attr,int pref);
So now my Question; Do I need to initialize a "rwlockattr" for every "rwlock" in my linked List or is it enough to set up a global "rwlockattr", initialize it and set up the "PTHREAD_RWLOCK_PREFER_WRITER_NP" rule ?
regards
With every rwlock there is some by default attributes associated with it. For the pthread_rwlock_init() go through this link which will give you more information that how to use rwlock.
You can assign single attribute to your rwlocks. You globally create a single attribute and assign to your rwlocks having the same nature.
Go through this to understand the use of pthread_rwlock.
In general Attributes are to decide the nature of your rwlock.