Coder Social home page Coder Social logo

garro95 / desim Goto Github PK

View Code? Open in Web Editor NEW
49.0 49.0 8.0 99 KB

A discrete-time events simulation framework, written in rust, using the generator experimental feature

License: GNU General Public License v3.0

Rust 100.00%
discrete events framework simulator time

desim's People

Contributors

0xjepsen avatar cjdrake avatar garro95 avatar lc525 avatar osolmaz avatar senden9 avatar shenjiangqiu avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

desim's Issues

API link dead

The link to the api docs on the repo landing page is dead.

Add new resource type: Store

pull request: #12

  1. motivation:
    the Store in simpy has a feature: the sender can wait on the store when the store is full and the receiver can wait on the store when the store is empty. So the scheduler needs to be changed when encountering Request and Release events
  • current behavior: when Request happened: the scheduler will issue one new event when the resource return Some event or zero when the resource returns None when Release happened: the scheduler will issue 2 events when the resource return Some event and issue 1 event(the original one) when the resource returns nothing.
  • new behavior:
    • when requesting on a store: the scheduler will need to schedule zero, one, or two events depending on the current store ( #12 ), as same as when releasing on a store
  1. things change from the original code:
  • change the Resource trait return type:
pub trait Resource<T> {
    fn allocate_or_enqueue(&mut self, event: Event<T>) -> Vec<Event<T>>;
    fn release_and_schedule_next(&mut self, event: Event<T>) -> Vec<Event<T>>;
}

instead of returning an optional value, the resource can now return zero or multiple events

  • change the scheduler behavior:
                            Effect::Request(r) => {
                                let res = &mut self.resources[r];
                                let request_event = Event::new(self.time, event.process(), y);
                                for e in res.allocate_or_enqueue(request_event) {
                                    self.future_events.push(Reverse(e))
                                }
                            }
                            Effect::Release(r) => {
                                let res = &mut self.resources[r];
                                let request_event = Event::new(self.time, event.process(), y);
                                let events = res.release_and_schedule_next(request_event);
                                for e in events {
                                    self.future_events.push(Reverse(e));
                                }
                            }

now the scheduler always schedules all the events that the resource returned.

  • chagne the original SimpleResource implementation: release will always return at least one event.
    fn release_and_schedule_next(&mut self, event: Event<T>) -> Vec<Event<T>> {
        match self.queue.pop_front() {
            Some(mut request_event) => {
                // some is waiting for the request, schedule it! and schedule the self
                request_event.set_time(event.time());
                vec![request_event, event]
            }
            None => {
                // no one is waiting for the resorce, restore the availiable and return self
                assert!(self.available < self.quantity);
                self.available += 1;
                vec![event]
            }
        }
    }
  1. new store type: see #12

Unresolved imports in v0.2

Hi,

Using desim v0.2 results in some import errors in the examples or when using desim as described in the examples.
For example, the carwash example does not compile with the following errors:

18 | use desim::prelude::*;
   |            ^^^^^^^ could not find `prelude` in `desim`

error[E0432]: unresolved import `desim::resources`
  --> simulator/src/bin/carwash.rs:19:12
   |
19 | use desim::resources::SimpleResource;
   |            ^^^^^^^^^ could not find `resources` in `desim`

In contrast, the example compiles successfully using the version on git , i.e. desim = {git = "https://github.com/garro95/desim"} .
The crate has not been updated on crates.io which is evident when looking at the last update on crates.io vs the commit history here.
It would be nice if you would update the crate.

Test log

Write a test to ensure that log trace is correct

desim new features (monitoring, callback_api, queuing disciplines, schedulers)

I'm trying to asses the opportunity for one or more pull requests that add some features to desim. Most of those are the result of my own needs for discrete event simulation, but I would like to see if there is wider interest:

Currently already done but in need of polishing (marked below) or in my near-term pipeline:

  • Improved monitoring, driven by user-provided data types (Effect + arbitrary additional state)
  • Event callbacks, currently implemented: on_event_processed, on_resource_acquire, on_resource_enqueue, on_resource_release
  • Allow for arbitrary resource queuing disciplines by providing a SimResource trait that all Resources implement
  • Schedulers (Time Sharing): I'm currently designing this so that sets of Processes can be logically run in a time-sharing fashion (each being given a time slice). This is more disruptive to the code as simulation steps are no longer entirely driven by resuming generators.

At the moment the new code lives in my own fork of desim in a "new_features" branch but that is just a messy experiment and separate pull requests would have to be teased from that. However, I don't plan on maintaining a separate fork if you are interested in the changes upstream.

accessing simulation time inside processes

Any idea how to access simulation time from within the process?

This code won't compile:

#![feature(generators, generator_trait)]
extern crate desim;
use desim::{Simulation, Effect, Event, EndCondition};

fn main() {


    let mut s = Simulation::new();
    let g = Box::new(|| {
        let tik = 0.7;
        loop{
            println!("tik {}", s.time());
            yield Effect::TimeOut(tik);
        }
    });

    let p = s.create_process(g);
    s.schedule_event(Event{time: 0.0, process: p});
    let s = s.run(EndCondition::Time(10.0));
}

The problem is accessing s from within the closure - it introduces immutable borrow of s with conflicts with the need to use the mutable borrow later. Any idea how to solve this without using Rc and RefCell?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.