garbage-free java.nio
Hello, recently I am interested in non-blokcing java api for networking. It seems to be great. However, I would like to implement garbage-free solution. I am trying to do it only for learning purpose (I know that I don't implement a "better" solution). Especially, my solution is going to be garbage-free. How to start? I see that jdk implementation is not garbage-free. And what? My only idea is to implement a small native library (only for Linux) and implement something like "facade" and a lot of stuff around that in Java (but, garbage-free). I suppose that it can be very hard to integrate it with selectors for example (if possible). But, I don't see another solution and this is why I wrote here. What do you think? What is the best approach? -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Looking at reordering memory operations
>
> That (t1 always see the same value of x when x is modified elsewhere) is
> possible, e.g. in a tight loop reading x and nothing else
>
And this is why I dislike when people say: "volatile field" ensures you
*only* about ordering. It is not true. Because it also means:
Mr javac/java/jit,
I synchronized access to that object so please be careful during reoderding
*AND* and optimization like: (Java perspective) I don't load the value from
the memory because noone can modify it (because it is not
volatile/synchronized- I have no clue that object is shared!)
Gil, thanks for your explanation.
W dniu piątek, 9 marca 2018 23:20:37 UTC+1 użytkownik John Hening napisał:
>
>
> executor = Executors.newFixedThreadPool(16);
> while(true) {
> SocketChannel connection = serverSocketChannel.accept();
> connection.configueBlocking(false);
> executor.execute(() -> writeTask(connection));
> }
> void writeTask(SocketChannel s){
> s.isBlocking();
> }
>
> public final SelectableChannel configureBlocking(boolean block) throws
> IOException
> {
> synchronized (regLock) {
> ...
> blocking = block;
> }
> return this;
> }
>
>
>
> We see the following situation: the main thread is setting
> connection.configueBlocking(false)
>
> and another thread (launched by executor) is reading that. So, it looks
> like a datarace.
>
> My question is:
>
> 1. Here
> configureBlocking
>
> is synchronized so it behaves as memory barrier. It means that code is ok-
> even if reading/writing to
> blocking
>
> field is not synchronized- reading/writing boolean is atomic.
>
> 2. What if
> configureBlocking
>
> wouldn't be synchronized? What in a such situation? I think that it would
> be necessary to emit a memory barrier because it is theoretically possible
> that setting blocking field could be reordered.
>
> Am I right?
>
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
