Forum Replies Created

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • CPUSpeedup
    Participant
    Post count: 8

    I’d like to know the opening thread answer and I’d like to ask a follow up question about the atomic model. I remember in a video there seemed to be an instruction to watch a memory address which you pair with a store. I think the store returns a bool saying if it succeeded or not? and it may fail if another core (or another store?) writes to that memory address? Perhaps I remember wrong. It was suppose to allow us to build primitives like a compare and swap?

    However in the wiki I see enterAtomic/exitAtomic/abortAtomic http://millcomputing.com/wiki/Instruction_Set/enterAtomic I guess the instructions I once saw no longer exit?

    • This reply was modified 8 months, 2 weeks ago by  CPUSpeedup.
  • CPUSpeedup
    Participant
    Post count: 8
  • CPUSpeedup
    Participant
    Post count: 8

    I think I should clarify. For something like read I imagine a portal call would happen and read would add the buffer/size/address to list of operations to be done in the service turf then sits in a loop yielding it’s thread time until the data is ready.

    However if I’m doing this async what implementation is available for the service to notify the client that the data is ready? I can’t imagine the service would ever want to use it’s own thread to do work for the client. Some implementations I can think of are

    1. Service thread uses a pointer to marks client data as available/%complete. Client sits in a loop checking to see if data is ready (and sleeping if nothing is ready)
    2. Service creates a new thread which then uses a portal to call client async code
    3. Service be able to interrupt client. Which appears to be a ‘knight move’ (changing the thread and turf) which you said is not possible on the mill.

    I was wondering which would be optimal or possible on the mill. For sure the first is possible, the third I suspect not. As for the second option is spawning a thread everytime less than optimal? If the app/client is poorly behaved and never returns from the portal callback could this cause problems?

    After writing this I suspect #1 is the safest most efficient method but a loop like this reminds me of a spinlock which probably isn’t expensive but isn’t my favorite method of notifying others of data

    • This reply was modified 8 months, 2 weeks ago by  CPUSpeedup.
    • This reply was modified 8 months, 2 weeks ago by  CPUSpeedup.
Viewing 3 posts - 1 through 3 (of 3 total)