Implementation of concurrency primitives
Cristian Lorenzetto
cristian.lorenzetto at gmail.com
Thu Nov 18 13:00:34 UTC 2021
also jdk api are containing inside many synchronized blocks....
unfortunatelly :(
Il giorno gio 18 nov 2021 alle ore 09:44 Andrey Lomakin <
lomakin.andrey at gmail.com> ha scritto:
> I see :-)
> The current version of my project is using only JDK API, at least the part
> which requires syncrhonization.
>
> On Thu, Nov 18, 2021 at 10:30 AM Cristian Lorenzetto <
> cristian.lorenzetto at gmail.com> wrote:
>
>> I had a idea similar in the past ... but the problem is many librariies
>> (also basic code) in java is using synchnorized blocks for example....
>> My project was , using instrumentation , to remove synchronized code for
>> adapting it to fibers ...
>>
>> Il giorno gio 18 nov 2021 alle ore 08:59 Andrey Lomakin <
>> lomakin.andrey at gmail.com> ha scritto:
>>
>>> Hi Cristian.
>>> Sure I would like to use CPU affinity at the end.
>>> But my primary concern is memory barriers or more widely thread safety.
>>>
>>> I mean the following, could I use for example HashMap instead of
>>> ConcurrentHashMap in such cases or more widely speaking, could I use data
>>> structures that were not designed to be thread-safe because I use
>>> cooperative multitasking and know that execution of methods
>>> will not be interrupted and in nutshell, all execution is running inside
>>> of the single thread, so that is a single-threaded application in nutshell
>>> with means to exchange data using threadsafe queues for example.
>>>
>>> On Thu, Nov 18, 2021 at 9:16 AM Cristian Lorenzetto <
>>> cristian.lorenzetto at gmail.com> wrote:
>>>
>>>> Interesting question, but i suspect it is not possible realize a custom
>>>> manager for that but you can use cpu affinity flag
>>>>
>>>> Il giorno gio 18 nov 2021 alle ore 07:44 Andrey Lomakin <
>>>> lomakin.andrey at gmail.com> ha scritto:
>>>>
>>>>> Good morning, guys.
>>>>>
>>>>> I am considering creating an application that will use a
>>>>> thread-per-core approach. Data mostly will not be shared between cores
>>>>> and
>>>>> I am going to use a single thread executor to schedule fibres.
>>>>>
>>>>> My question is may I use my own concurrency primitives which do not
>>>>> inject
>>>>> memory barriers unlike the standard concurrency primitives to
>>>>> achieve maximum performance and if that is not possible could you
>>>>> explain
>>>>> why?
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Andrey Lomakin.
>>>>>
>>>>
>>>
>>> --
>>> Best regards,
>>> Andrey Lomakin.
>>>
>>>
>
> --
> Best regards,
> Andrey Lomakin.
>
>
More information about the loom-dev
mailing list