The SPP example seems like a perfect fit for your needs:
https://docs.silabs.com/bluetooth/2.13/code-examples/applications/spp-serial-port-profile-over-ble

The sl_bt_gatt_server_send_notification() function returns SL_STATUS_OK if successful, error code otherwise. If an error occur during execution in the stack, an sl_bt_evt_system_error event occur with a specific error code. 

The question was how to know that the notification has finished. The OK return code just means that the BLE stack in the transmitting side has queued the notification, but it does not mean it has been sent successfully to the remote device. As OP pointed out, the Nordic BLE stack has an event that is raised when notification is complete. The user application can use this for example to keep track of how many notifications are queued at the moment.

 

Andreas, I think the problem is that the BLED112 does not support multiple connections in peripheral mode. It is a Bluetooth 4.0 device and the support for multiple connections in slave role was added in Bluetooth core spec 4.2 if I remember right.

If the dongle is the central / initiator, it can connect to multiple (up to 8) peripherals simultanously. But in peripheral mode the dongle supports only one connection.

 

It does not really matter if the central device is a mobile app or not. The data transfer over BLE connection works so that user application does not need to worry about conflicts. 

For reference, You can have a look at the SPP example:
https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/04/13/spp-over-ble_c_examp-mnoe

 

The SPP example uses same characteristic (spp_data) for both incoming and outgoing data using write-without-response and notifications. The data streams are not coordinated in any way but still the example works just fine. I have personally tested it so that high amount of data is streamed both in and out at the same time and it works just fine. 

You don't need to worry about the collision, the stack will take care of that for you and it makes sure no data is lost.

 

For reference, You can have a look at the SPP example:
https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/04/13/spp-over-ble_c_examp-mnoe

 

The SPP example uses same characteristics (spp_data) for both incoming and outgoing data using write-without-response and notifications. The data streams are not coordinated in any way but still the example works just fine. I have personally tested it so that high amount of data is streamed both in and out at the same time and it works just fine. 

You don't need to worry about the collision, the stack will take care of that for you and it makes sure no data is lost.

 

Is it possible to perform write without response and notify operation at a same time in different characteristic?

Yes it's possible. Strictly speaking, the two operations would not be happening simultaneously but from the application perspective you should not see any difference. I don't think there will be any problems even if you use the same characteristic for input/output data.

 I want to know what will happen and what is sequence of flow of data  if write operation and notification happen in same time.

Are you interested in what are all the details at radio packet level? If you just want to have reliable data flow in both directions then you probably don't need to worry at all about the low level details. There should not be any conflicts (resulting in lost packets or dropped connections) if you are sending data both ways at the same time. The stack can take care of that. 

If you need to control precisely at packet level what is the order of packets being sent in each direction, the you probably should not be using notify and write-without-response in the first place. But I guess you are just concerned about what happens if the incoming and outgoing data streams "collide", am I right?

 

Is it possible to perform write without response and notify operation at a same time in different characteristic?

Yes it's possible. Strictly speaking, the two operations would not be happening simultaneously but from the application perspective you should not see any difference. I don't think there will be any problems even if you use the same characteristic for input/output data.

 I want to know what will happen and what is sequence of flow of data  if write operation and notification happen in same time.

Are you interested what are all the details at radio packet level? If you just want to have reliable data flow in both directions then you probably don't need to worry at all about the low level details. There should not be any conflicts (resulting in lost packets or dropped connections) if you are sending data both ways at the same time. The stack can take care of that. 

If you need to control precisely at packet level what is the order of packets being sent in each direction, the you probably should not be using notify and write-without-response in the first place. But I guess you are just concerned about what happens if the incoming and outgoing data streams "collide", am I right?

 

Is it possible to use bonding for the connection? Notification/indication subscriptions are stored permanently for bonded devices, meaning you would only need to subscribe once. Then after disconnect and reconnect the subscription status (value of CCCD) should be restored to the same value as it was in the previous connection.

But the issue is with connection, it is giving some gatt service conn time  out error.

It's better to create a new topic/thread for this connection issue. Also, you need to provide more details about the error (does it happen every time you try to connect etc..)