Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Patch implementing inter-thread shared variable without creating a new thread. #4554

Closed
vicuna opened this issue May 17, 2008 · 4 comments
Closed

Comments

@vicuna
Copy link

@vicuna vicuna commented May 17, 2008

Original bug ID: 4554
Reporter: ogasawara
Status: acknowledged (set by @damiendoligez on 2008-09-23T17:41:07Z)
Resolution: open
Priority: normal
Severity: feature
Version: 3.10.2
Category: otherlibs
Tags: patch

Bug description

Hello,
First of all, thanks for the excellent job.

I would like to suggest a new feature about Event module.

Event module provides CML style synchronous communication methods,
but does not support shared variables like ivar, mvar.
These variables are REALLY necessary for multi-thread programming.

So, I have implemented shared variable module called 'Cell'.

  1. With 'Cell', we can make ivar, mvar, thread-safe queue, broadcast channel,
    and timeout event easily.

  2. 'Cell' dose not create a new thread. This is IMPORTANT. It means the shared
    variable is GC target. If the variable has a thread, it is impossible to garbage
    collect automatically.
    But, to make such shared variable with Event module, Cell module is inside of
    Event module because implementation detail of Event.event type is needed.

Type of Cell module inside Event module is as follow:

module type Cell = sig
  type 'a t
  val make : unit -> 'a t
  val init_make : 'a -> 'a t
  val put : 'a t -> 'a -> unit Event.event
  val take : 'a t -> 'a Event.event
  val read : 'a t -> 'a Event.event
  val overwrite : 'a t -> ('a -> 'a) -> unit Event.event
end

I'm sending a patch to Event module with some sample code for testing.

Thanks,

ogasawara

File attachments

@vicuna
Copy link
Author

@vicuna vicuna commented Jun 20, 2008

Comment author: ogasawara

I found that first version patch had several bugs.
I have made more tested version and uploaded.

@github-actions
Copy link

@github-actions github-actions bot commented May 18, 2020

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 18, 2020
@mshinwell
Copy link
Contributor

@mshinwell mshinwell commented May 18, 2020

@kayceesrk Presumably multicore will provide other methods of dealing with such problems, so it would be appropriate to close this?

@kayceesrk
Copy link
Contributor

@kayceesrk kayceesrk commented May 18, 2020

Yes. Domainslib already provides channels (without selective communication a la CML). These features do not (and should not) need to live in the compiler distribution. Hence, it is appropriate to close this one.

@github-actions github-actions bot removed the Stale label Jun 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.