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

Let's implement threads.mutex #12

Closed
levBagryansky opened this issue Aug 31, 2022 · 23 comments
Closed

Let's implement threads.mutex #12

levBagryansky opened this issue Aug 31, 2022 · 23 comments
Assignees
Labels
enhancement New feature or request

Comments

@levBagryansky
Copy link
Member

@yegor256 Let's implement mutex object. It will have mutex.lock and mutex.unlock attributes so only one thread can own the mutex in a moment.

@levBagryansky
Copy link
Member Author

@yegor256 Can I do it?

@yegor256
Copy link
Member

yegor256 commented Sep 1, 2022

@levBagryansky sure, but I would name them acquire and release:

QQ.threads.mutex >
m.acquire > a
a.release

This is the most logical way of dealing with locks, I believe

@yegor256 yegor256 added the enhancement New feature or request label Sep 1, 2022
@levBagryansky
Copy link
Member Author

levBagryansky commented Sep 1, 2022

@yegor256 ok. I thought lock and unlock should return TRUE. So we would use it like

[] > app
  QQ.threads.mutex > m
  seq > @
    m.acquire
    m.release

But do m and a in your sample refer to the same object?

@levBagryansky
Copy link
Member Author

@yegor256 Will we use mutex in this way:

[] > app
  QQ.threads.mutex > m
  seq > @
    m.acquire
    do-smth
    m.release

?

@yegor256
Copy link
Member

yegor256 commented Sep 2, 2022

@levBagryansky in this case we can only acquire ONE lock, while a proper mutex should allow multiple of them:

[] > app
  QQ.threads.mutex 2 > m
  seq > @
    m.acquire > first
    do-smth
    m.acquire > second
    first.release
    second.release

The number of locks in the mutex should be a mandatory argument of mutex.

@levBagryansky
Copy link
Member Author

levBagryansky commented Sep 2, 2022

@yegor256 How can we lock the already existing mutex if acquire locks a new mutex? We can not do:

[] > app
  mutex > m
  thread > t1
    seq > @
      m.acquire
      do-smth1
      m.release
  thread > t12
    seq > @
      m.acquire
      do-smth2
      m.release
  seq > @
    t1.start
    t2.start
    t1.join
    t2.join

@levBagryansky
Copy link
Member Author

@yegor256 may be we can write

[] > app
  QQ.threads.mutex' > m

to create a new mutex?

@yegor256
Copy link
Member

yegor256 commented Sep 2, 2022

@levBagryansky our mutex should be very similar to https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Semaphore.html But it would be better to have "personalized" locks: if you acquire one, you must return exactly the same one. That's why:

mutex 100 > m
m.acquire > a
a.release  # instead of m.release

@levBagryansky
Copy link
Member Author

levBagryansky commented Sep 2, 2022

@yegor256 So when in the same time another thread will do
m.acquire > b will it wait for a.release if mutex was created with num 1?

@yegor256
Copy link
Member

yegor256 commented Sep 2, 2022

@levBagryansky yes, of course

@levBagryansky
Copy link
Member Author

@yegor256 ok thanks

@levBagryansky
Copy link
Member Author

@yegor256 Must the second a.release be legal or cause an error?

@yegor256
Copy link
Member

yegor256 commented Sep 6, 2022

@levBagryansky must cause and error, of course

@levBagryansky
Copy link
Member Author

@levBagryansky our mutex should be very similar to https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Semaphore.html But it would be better to have "personalized" locks: if you acquire one, you must return exactly the same one. That's why:

mutex 100 > m
m.acquire > a
a.release  # instead of m.release

@yegor256 Seems it is impossible to use personal locks. Imagine we have this code:

[] > twice-lock
  mutex 1 > m
  seq > @
    m.acquire > a
    a.release

mutex.acquire is a personal lock. Because of a is a result of dataization m.acqure lock must have delta-attribute, for example TRUE. When seq dataizes m.acquire the first time a is a TRUE. But when it tries to dataize a.release it go to a and again acquires mutex to return lock without its dataization. Since we acquire the mutex twice we are in dead lock.
Its a problem I faced.

@yegor256
Copy link
Member

yegor256 commented Sep 7, 2022

But when it tries to dataize a.release it go to a and again acquires mutex to return lock without its dataization

@levBagryansky I don't think it's true. In order to dataize a.release EO doesn't need to dataize a.@

@levBagryansky
Copy link
Member Author

@yegor256 It does not dataize a.@ but is dataize m.acquire again. I can demonstrate it.
This is simplified mutex implementation:

[] > mutex
  [] > acquire
    seq > @
      QQ.io.stdout "Acquire\n"
      lock

  [] > lock
    TRUE > @
    [] > release
      TRUE > @

This is the test:

[] > twice-lock
  mutex > m
  seq > @
    m.acquire > a
    a.release

When we run the test it ptints "Acquire" twice that poves it would acqure the mutex twice:

[INFO] Running EOorg.EOeolang.EOthreads.EOtwice_lockTest
Acquire
Acquire
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 s - in EOorg.EOeolang.EOthreads.EOtwice_lockTest

@0pdd
Copy link

0pdd commented Sep 15, 2022

@levBagryansky 2 puzzles #33, #34 are still not solved.

@0pdd
Copy link

0pdd commented Oct 3, 2022

@levBagryansky 5 puzzles #33, #34, #51, #52, #53 are still not solved.

@0pdd
Copy link

0pdd commented Oct 6, 2022

@levBagryansky 4 puzzles #33, #34, #52, #53 are still not solved; solved: #51.

@0pdd
Copy link

0pdd commented Oct 6, 2022

@levBagryansky 3 puzzles #33, #34, #52 are still not solved; solved: #51, #53.

@0pdd
Copy link

0pdd commented Oct 7, 2022

@levBagryansky 2 puzzles #33, #52 are still not solved; solved: #34, #51, #53.

@0pdd
Copy link

0pdd commented Oct 12, 2022

@levBagryansky the puzzle #33 is still not solved; solved: #34, #51, #52, #53.

@0pdd
Copy link

0pdd commented Oct 17, 2022

@levBagryansky all 5 puzzles are solved here: #33, #34, #51, #52, #53.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants